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Introduction 


This book covers the topic of satellite control centers. We'll take a 
look at the historical development of satellite control centers, from 
the earliest efforts of the iconic Apollo Mission Control at Houston. 
Mention a spacecraft control center, and every one remembers the 
one from the movie Apollo-13. 


The primary focus will be NASA efforts, but similar facilities are in 
use by other spacefaring nations. This book is intended as an 
technical introduction to the subject. We'll look at the evolution of 
satellite control centers to understand how we got to where we are, 
and we'll look at evolving technology to see where we can go. 


As technology advances, we have a better basis for control centers, 
as well as cheaper yet more capable hardware, and better and more 
available software. With the proliferation of inexpensive Cubesat 
projects, colleges and universities, high school, and even individuals 
are getting their Cubesats launched. They all need control centers. 
For lower cost missions, these can be shared facilities. 
Communicating with and operating a spacecraft in orbit or on 
another planet is challenging, but is an extension of operating any 
remote system. We have communications and bandwidth issues, 
speed-of-light communication limitations, and complexity. Remote 
debugging is a always a challenge. 


The satellite control center is part of what is termed the Ground 
Segment, which also includes the communication uplink and 
downlink. The control center generates uplink data (commands) to 
the spacecraft, and receives, processes, and archives downlink 
(telemetry) data. The spacecraft is usually referred to as the space 
segment. The spacecraft usually consists of a “bus”, the engineering 
section, and the payload, either a science instrument package or a 
communications package. Satellite busses can be “off-the-shelf,” 
leading to economies of scale. 


This book was compiled from ITAR-compliant sources. 
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Author 


Mr. Patrick H. Stakem has been fascinated by the space program 
since the Vanguard launches in 1957. He received a Bachelors 
degree in Electrical Engineering from Carnegie-Mellon University, 
and Masters Degrees in Physics and Compute Science from the 
Johns Hopkins University. At Carnegie, he worked with a group of 
undergraduate students to re-assemble and operate a surplus Athena 
missile guidance computer. It was brought up to operational status, 
and modified for general purpose use. 


He began his career in Aerospace with Fairchild Industries on the 
ATS-6 (Applications Technology  Satellite-6), program, a 
communication satellite that developed much of the technology for 
the TDRSS (Tracking and Data Relay Satellite System). He 
followed the ATS-6 Program through its operational phase, and 
worked on other projects at NASA’s Goddard Space Flight Center 
including the Hubble Space Telescope, the International Ultraviolet 
Explorer (IUE), the Solar Maximum Mission (SMM), some of the 
Landsat missions, and others. He was posted to NASA’s Jet 
Propulsion Laboratory for MARS-Jupiter-Saturn (MJS-77), which 
later became the Voyager mission, and is still operating and 
returning data from outside the solar system at this writing. 


Mr. Stakem is affiliated with the Whiting School of Engineering of 
the Johns Hopkins University, and Capitol Technology University. 


Control Center — what it is, what it does. 


A satellite control center has a wide variety of task. It provides 
services to the mission 24x7x365. These services include the 
reception, archiving, limit-checking, and conversion of the received 
telemetry data. Today, received telemetry is archived in raw form, 
and saved in engineering units in a database. Use of a standard 
commercial database simplifies operations and controls costs. The 
Control Center disseminates selected data to users, either located in 
a control room, or via the web. The Control Center is usually built 
around a STOL, or scripting language, for automation of operations 
where possible. The software does limit checking of incoming data, 
and issues alerts if limits are exceeded. The control center also is 
responsible for commanding the spacecraft. 


Early in the Mission definition, various Operations Concepts (Ops 
Concepts) are defined, and these lead to requirements. The Ops 
Concepts drive the architecture of the Control Center. There must be 
sufficient flexibility for the Ops Concepts to evolve, as the mission 
progresses. 


The Control Center provides work space, data systems for telemetry, 
command capability, and coordination of activities between 
subsystems. The Control Center is responsible for spacecraft 
planning and scheduling. It is usually operating 24 x 7. The Control 
Center becomes a busy place during spacecraft anomaly or failure 
situations. It is the workplace for the flight operations team. 
Generally, the Control Center has a front room, and a back room. 
The front room is responsible for all real time activities, and 
commanding. The back room is for off-line analysis. Different 
personnel may inhabit the back room at different times and mission 
mission phases. In the early days of spacecraft, the control center 
function was done from the launch site, or a tracking station. As 
spacecraft computers become more powerful, some of the functions 
of the control center can be done onboard. In addition, the control 
center architecture has evolved from mainframe computers, to the 
client-server architecture, to pc's, and then to distributed models, 
based on the cloud. It is important, though, to still have a defined 
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control center “space” where the operations team can congregate. 


Here are some of the tasks that need to be done to support a space 
mission. Not all are applicable to all missions. The Control Center 
can be large and complex, such as an entire building for the Hubble 
Space Telescope, or simple, like a laptop-based control center for a 
Cubesat. 


Planning and Scheduling 

Commanding 

Onboard engineering support (housekeeping) 
Downlink and data archiving 

Performance monitoring fault detection and diagnostics 
Fault correction; redundancy management; 

Calibration 


We'll discuss how and where these functions are done later. Some of 
these functions can be automated, and some can be accomplished 
onboard. 


Functional areas of the Control Center include Flight/Mission 
Control (Systems level); Guidance, Navigation, and Attitude 
Control, Thermal monitoring, Electrical Power, Onboard Computer 
and Data System, Communication and RF, and Payload operations. 
Each of these generally maps to a seat in the Control Center, with a 
Team lead, typically a Systems Engineer, in charge. 


The Planning and Scheduling function is off-line, ahead of the time 
it will be needed. It will result in a detailed, optimized schedule of 
operations, for a 24-hour period or longer. It may involve complex 
predictive modeling of the spacecraft and its environment. Once the 
time-line is verified, it will be mapped into commands and sent to 
the spacecraft for execution. There are also contingencies for special 
conditions and anomalies. These are done ahead of when they are 
needed. 


Some items that might have to be factored into the time-line include 
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entrance and exit from the South Atlantic Anomaly (SAA) radiation 
zone, which might require turning off certain sensitive equipment. 
There is also the issue of Earth occultation (when the spacecraft is 
on the opposite side of the Earth from the Sun, and thus has no solar 
power), and possibly a lunar eclipse, which will also block the Sun. 

If we are relying on sensing the Earth's rim to keep pointing to a 
desired terrestrial target, we must also know when the Sun will blind 
the horizon sensor. It is also possible that the moon will be partially 
obscured by the Earth from the spacecraft's point of view, and a 
horizon sensor would see that as a “bigger” Earth. We need to know 
when the spacecraft is in line-of-sight with a ground station, or a 
TDRSS satellite, and when it has no-communication “dark zones.” 


And then, there's orbital decay and debris to worry about. Due to the 
very small but finite atmosphere, there is orbital drag, and the 
spacecraft thrusters may need to be used to adjust for this. A strong 
Solar Wind or Solar storm can also affect the orbit. Orbital debris is 
an increasing problem. Each mission is now required to have an 
end-of-life plan, usually involving reentry. There are literally 
hundreds of thousands of insert orbital objects tracked, from upper 
stage boosters, to zombie-sats, to bolts. At the orbital speeds 
involved, even a grain of dust can carry significant energy to be a 
lethal projectile. These data are available from the NORAD website. 
Another set of data that is needed in scheduling is the Ephemeris of 
the satellite, its position and path. Both of these items will be 
discussed later in the book. 


Engineering support, or housekeeping activities, are accomplished 
according to schedule, or in response to conditions. An example is 
momentum unloading. To keep properly oriented, the spacecraft 
may use momentum wheels. These are spun at high speed to move 
the much more massive spacecraft in the opposite rotation, slowly. 
The problem is, there are biases in the gravity field that cause the 
momentum wheels to become saturated at some point, days, usually. 
How can we get rid of this momentum, there's nothing to push 
against? Actually, there is. We can push against the Earth's magnetic 
field. That requires a map of the field, from the spacecraft's point of 
view. Momentum wheel unloading can be adjusted accordingly. The 


8 


spacecraft can also fire thrusters, to unload the wheel's momentum. 
This requires us to keep track of the amount of onboard fuel and 
oxidizer, or cold gas that was used. The thrusters can also be used to 
adjust the orbit. 


Another commodity that has to be tracked is the amount of onboard 
storage for data. This might fill up, and need to be “dumped” to the 
ground when a communication channel is available. The spacecraft 
will need to point its solar arrays for getting the maximum power, its 
communication antenna to get the best signal, and perhaps movable 
parts of the science payload. 


Onboard status monitoring is common today, but should still be 
backed up with ground-based monitoring and trending. It is usual to 
have spare components (4 momentum wheels when we only need 
three; redundant radios, etc). Spares management and planning for 
“Plan B”is critical when configuration changes are needed due to 
degradations and failures. Part of this can be derived from a good 
Failure Modes and Effects Analysis (FMEA) done during the design 
and testing process, and kept updated throughout the program. 


Historical Examples 


How do we talk and listen to satellites, send them commands, and 
receive their data? How did satellite control centers evolve? This is a 
data question. The radio portion of the uplink (to the satellite) and 
downlink (from the satellite) is off-the shelf. Satellites can now be 
considered as nodes on a network, which means we have fewer 
details to worry about. Initially, computers were big, unique, heavy 
mainframes with a dedicated priesthood of programmers and system 
engineers to keep them running. They were enshrined in specially 
air conditioned rooms with raised floors and access control. They 
ran one job at a time, taking punched cards as input, and producing 
reams of wide green-striped paper output. Data were collected on 
reels of magnetic tape, or large trays of punched cards. Access to 
these very expensive resources was necessarily limited. 


Then, a better idea evolved. Most of the time, the “big iron” was not 
computing, it was waiting. So, if we could devise a way to profitably 
use the idle time, we would increase the efficiency of the facility. 
This lead to the concept of time-sharing. There was a control 
program whose job it was to juggle the resources so that a useful 
program was always running. This came along about the time that 
remote terminals were hooked to the mainframe, to allow access 
from multiple, different locations. In a sense, the computer facility 
was virtualized; each user saw his or her very own machine ( for 
limited periods of time, anyway). If the overhead of switching 
among users was not too great, the scheme worked well. 


This evolved into a “client-server” socket-type architecture, in 
which the remote clients had some compute and storage capability 
of their own, but still relied on the server. 


In the background, something else amazing was happening. 
Mainframes were built from relays and vacuum tubes, magnetic core 
memory, and massive rotating magnetic drums for storage. 
Eventually, semiconductor devices began to take over. 
Semiconductor technology scales nicely. In fact, Gordon Moore of 
Intel formulated his famous law from observations that the 
complexity of the devices doubled every 18 months. This is an 
exponential growth curve. If we have | unit of memory in a package 
for a certain cost, in 18 months we will have 2 units of memory in 
the same package for the same price. In 18 more months, 4 units, 
and so on. 


It doesn’t take long for this to really add up. And, the technology 
feeds on itself. The computers used to design and manufacture chips 
keep getting more and more capable. 


Now, our phones have orders-of-magnitude more compute and 
storage capability than mainframes. My tablet has more capability 
than my entire University had when I was an undergraduate. Such 
exponential growth laws can’t be sustained forever, but, so far, so 
good. 
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Communications, drawing on the same technology, has vastly 
improved as well. NASA's data transmission system in the early 
days used their own and leased landlines, with ships and aircraft to 
fill in the gaps over the ocean. Now, satellite data is relayed between 
spacecraft, and a series of geostationary Tracking and Data Relay 
Satellites allow for almost complete coverage. Data that used to 
travel over dedicated lines now moves on the Internet infrastructure, 
which includes ground and under-sea fiber optic cable, and 
communications satellites as well. Coverage is provided to the Polar 
regions by communications satellites in Polar orbit. Yes, Antarctica 
has good Internet coverage. 


Rapid changes in technology that effect how we do things, or enable 
us to do new things, are called paradigm shifts. Sometimes these are 
gradual, and sometimes abrupt. Get used to it. We'll examine some 
of the historical and evolutionary satellite control centers. The 
Architecture evolved into a workable system, and we use this today, 
albeit implemented in different technologies. Today, do you want to 
get your satellite data on your smart watch? — no problem. 


Early manned missions 


In Project Mercury and Gemini in the early 1960's, operations were 
generally carried out from a control room at the launch site, Cape 
Canaveral. Tracking stations around the world supplied command 
and data, with gaps in the coverage. Aircraft and tracking ships filled 
in some of the gaps, for critical periods. The NASA “Navy” 
consisted of the Coastal Sentry Quebec in the Atlantic, and the Rose 
Knot Victor in the Indian Ocean. 


Apollo Mission Control 


Control and authority over the Apollo missions transitioned from the 
Kennedy Space Center (KSC) launch site to Johnson Space Center 
(JSC) Mission Control when the vehicle cleared the launch tower, 
which took about 12 seconds. This was the scenario for all of the 
Saturn vehicle flights, from the in-orbit tests through the lunar 
missions, and later, Skylab. 
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The Control Centers were later used for the Shuttle flights. The 
Houston one is being used to support Space Station operations, in 
addition to one at Marshall. The JSC Facility has been renamed the 
Christopher C. Kraft Mission Control Center, after the famous 
Apollo-era flight director. It consists of one large operational control 
center that operates 24x7, with resources for the various flight 
controllers. Because of the possibility of hurricanes in the Houston- 
Gulf area, there are backup sites at MSFC in Huntsville, and GSFC 
in Maryland. The design for the original Control Center developed 
for the Apollo Lunar landings was driven by a large IBM Mainframe 
Computer (System S/360). A similar configuration was used at 
Goddard and Marshall. These facilities were up and operational 
during any Mission, and could assume control quickly. NASCOM, 
the NASA worldwide communication network, was located at 
Goddard Space Flight Center, and connected to the world-wide 
network of tracking stations and tracking ships. Aircraft were also 
used to fill in gaps in the coverage. All the data flowed into the 
basement of Building 14 at Goddard, and was sent to the various 
NASA Centers as required. A direct line from the launch site in 
Florida to the Marshall Space Flight Center in Alabama was 
maintained. 


The Real Time computer complex at Mission Control in Building 30 
at JSC was based on five IBM mainframes of the System/360 
family. The previous Gemini Missions had been supported by up to 
five of the IBM 7094-II computers. Gemini involved the 
simultaneous operation of two spacecraft in orbit (for rendezvous), 
and introduced video graphics displays. Mission control for Mercury 
and early Gemini had been done at the Kennedy Launch Center. The 
Control Center in Houston got the first S/360 shipped by IBM. The 
operating system OS/360 was not well suited to real time operations, 
being designed for batch processing. IBM introduced a real-time 
version, RTOS/360, with better real time response. Five NASA 
S/360 model 75's were used at JSC. 


The ground tracking stations were supplemented by the EC-135A 
ARIA (Apollo Advanced Range Instrumentation) aircraft, that were 
more than just data relays; they had a limited control center onboard 
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as well. These flew from 1968 to 2001, supporting a variety of 
missions beyond Apollo. 


Ref: http://www. flyaria.com/ 


The Mission Operations Control Centers at JSC and Kennedy Space 
Center were added to the list of National Historical Landmarks. 


“The Model 75 was an outgrowth of IBM's continuing engineering 
development effort to enhance the capabilities of the original 
System/360 offerings. Its main memory operated at 750 
nanoseconds and was available in three sizes up to 1,048,576 
characters of information. The memory was interleaved up to four 
ways to obtain increased performance. 


The Model 75 superseded the original Model 70 of the System/360 
family, which had been announced a year earlier. Manufactured at 
IBM's plant in Kingston, N.Y., the Model 75 had a monthly rental 
range of $50,000 to $80,000, and a purchase price range of $2.2 
million to $3.5 million. Deliveries began during the fourth quarter of 
1965.” 


The S/360 series used punch card input, and large line printers for 
output. They used the IBM channel architecture for I/O, including 
disk and 9-track tape drives. 


The Model 75 was near the top of the System/360 family in terms of 
size and performance. In the System/360, an 8-bit byte was 
standardized, and memory was byte addressable. Words were 32-bits 
in size, in big-endian format. CPU's were microcoded, and floating 
point operations were supported. Twenty-four bit addressing was 
supported, as were prioritized interrupts, crucial for real-time 
operation. 


Generally, only one computer would be on-line during a mission, 
with one more in backup mode. Every hour, the on-line system was 
backed up to magnetic tape, so a complete transition could be made 
in the case of failure. During launch and critical operations, two 
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machines were kept on-line. There were five units, so two Apollo 
missions or simulations could be supported simultaneously. 


The Command, Communication, and Telemetry System (CCATS) 
handled input/output, and used three Univac 494 computers. These 
were 30-bit machines with 131K to 262K of core memory. Up to 24 
I/O channels were available and the system was usually shipped 
with UNIVAC magnetic drum storage. The basic operating system 
was OMEGA. For real time commanding at the commanding uplink 
station, a Univac 124B computer was used. 


Reference: 


http://arstechnica.com/information-technology/2014/04/50-years- 
ago-ibm-created-mainframe-that-helped-bring-men-to-the-moon/ 


Space Shuttle Mission Control 


Shuttle flights were controlled from an upgraded facility at the 
Johnson Space Center in Houston, called the Mission Control Center 
(MCC). As with Apollo, responsibility for the flight transitioned 
from the Kennedy Space Center launch site to Houston, when the 
vehicle had cleared the launch tower. The MCC controlled the 
mission until the Shuttle landed and rolled to a stop on the runway. 
The MCC had supported more than 60 manned missions, starting 
with Gemini 4 in 1965. 


The MCC is located in Building 30 at JSC, and has dual independent 
Flight Control Rooms. This provides redundancy, as well as the 
ability to support two missions at once. The second floor facility was 
used for NASA Missions, with the third floor facility being used for 
DoD missions. 


Being in a hurricane-prone region in south Texas, near the Gulf of 


Mexico, the JSC needed to have further backup in case they were 
shut down. In the Apollo era, this was provided by the Goddard 
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Space Flight Center in Greenbelt, Maryland. For the later Shuttle 
missions, the backup was the White Sands Test Facility in New 
Mexico. 


Supporting a Shuttle mission required teams of 30, working in 8 
hour shifts, 24x7. Each team, consisting of engineering discipline 
experts, was headed by a flight director. Besides the specific 
engineering subsystem knowledge, the teams evolved to support 
specialized flight phases. There was a team expert in ascent, return, 
in-space operations, and mission planning, 


Besides the teams, there were numerous NASA and contractor “back 
office” support staff, as needed and on-call. 


The flight control room had 16 consoles, supporting the Flight 
Director; the CapCom; Flight Dynamics Officer; Guidance Officer: 
Data Processing System Engineer; Flight Surgeon; Booster Systems 
Engineer; Propulsion Systems Engineer; Guidance, Navigation and 
Control Engineer; Electrical, Environmental, and Consumables 
System Engineer; Instrumentation and Communications System 
Engineer; Ground Controller, Flight Activities Officer; Payloads 
Officer; Maintenance, Mechanical Arm, and Crew Systems 
Engineer, and a Public Affairs Officer. Besides the consoles, the 
MCC had large projection screens at the front of the room which 
could show data or live television. 


Marshall Space Flight Center was the lead center for payloads 
onboard Shuttle flights. It had a Payload Operations Control Center 
in Building 30 that supports these activities. It would be 
reconfigured between Shuttle flights for the particular payloads 
carried. When a flight was not being supported, the facility was used 
for training and simulation. During a mission, a typical team was 10 
people. 


Unmanned missions, near-Earth 


NASA's unmanned near-earth missions are the responsibility of the 
Goddard Space Flight Center in Greenbelt, Maryland. Initially, 
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control centers were as different and unique as the early spacecraft 
themselves. As more satellite series came along (TDRSS, NOAA 
weather satellites) there was a corresponding similarity in control 
centers. 


These spacecraft are built on same standardized bus architecture, 
and may have the same payload. An early example of this is GSFC's 
MultiMission Modular Spacecraf (MMS), which could support a 
wide variety of missions, and was compatible with the shuttle for 
launch, retrieval, and servicing. The Hubble Space Telescope is 
build on the MMS bus. 


Building 14 was the operational nerve center for NASA Goddard 
Missions. An early control room for the orbiting Astronomical 
Observatory (OAO) was located in the basement of Building 14. 


During launch operations, the mission control room monitors the 
satellite(s), referred to as the “payload.” The launch control center 
has control of the mission at this time, until the payload separates 
from the launch vehicle. This is usually within 10-15 minutes after 
launch. 


StSOI 


The Space Telescope Science Operations Institute is located on the 
campus of The Johns Hopkins University in Baltimore, Maryland. It 
operates the science program for the Hubble Space Telescope and 
will conduct the science and mission operations for the follow-on 
James Webb Space Telescope after it is launched. It supports other 
astronomy programs and conducts world-class scientific research 
with 500 scientists and engineers. It provides the functions of data 
archiving, analysis and processing, and spacecraft planning and 
scheduling. 


POCC 


The Payload Operations Control Center (POCC) was a concept 
developed at GSFC to leverage the similarity of spacecraft using the 
MMS.. Rather design each control center from scratch, a baseline 
architecture was defined that would apply across missions, while 
allowing the flexibility to customize services. The evolution of this 
concept is still used today in Control Center Architecture. A generic 
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control center architecture evolved, which scopes all the activities of 
a wide range of spacecraft. The use of standards both in the 
spacecraft system and on the ground facilitates this. The control 
center can be customized, essentially, by a configuration database. 
This works particularly well with constellations of similar or 
identical spacecraft. In support of constellations, we focus on the 
similarities, but need to track the individuality's of different units. As 
the constellation ages, the operational characteristics diverge. By 
careful trending, we can predict and perhaps prevent failures in other 
units. 


In addition, there is an advantage to schedule and cost to developing 
the control center software early, and using it to support Integration 
and Test of the spacecraft. The biggest advantage, beyond avoiding 
two development efforts, is avoiding two validation activities. A 
huge amount of verification for each telemetry point and each 
command is_ required. Modern Control Center (software) 
architectures such as COSMOS follow this approach. It also helps in 
training operators. 


Deep Space Missions 


For U. S. missions beyond the near-Earth, the responsibility falls to 
California Institute of Technology's Jet Propulsion Laboratory, under 
contract to NASA. The control center's for the various missions tend 
to resemble those used at Goddard Space Flight Center for near 
Earth missions. They are purpose-built, since each mission is highly 
unique. Some JPL missions operate for decades or multiple decades, 
so a technology refresh is sometimes required. Their Mission control 
rooms are called OCC, Operations Control Centers, and the Space 
Flight Operations Facility, SFOF. 


These rooms are a flurry of activity at launch, but can be mostly 
deserted during a long cruise. Then things get busy again during a 
planetary fly-by or landing. 


JPL, in Pasadena, California, is in an earthquake zone, and this is 
considered in control center construction, and geographic diversity. 


For Mars missions, the Control Center and staff operate on Martian 
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Time. The Martian day is some 40 minutes longer than the Earth 
Day, so schedules constantly slide. 


The Johns Hopkins University, Applied Physics Laboratory in 
Laurel, Maryland has a satellite control center on its campus, as was 
spotlighted during their 2014 New Horizons mission to Pluto. 


Control Center Architecture, Hardware/ 
Software 


This section discusses the hardware and software architecture of the 
Control Center. Basically, a Control Center needs a certain level of 
data communication and storage capacity, a figure that is provided 
by most modern desktop and laptop machines, as well as some 
tablets. 


Spacecraft Simulator 


A good simulator is critical in the Control Center, particularly for 
initial checkout and for personnel training. The simulator can be 
developed before or concurrent with the Control Center itself, and 
used for validation. In operational use, the simulator can be used for 
anomaly investigation and to develop new scenarios. It can 
implemented on the same computer architecture that drives the 
displays and does the calculations in the control center. 


It is essential that the simulator data be tagged in the header. Don't 
do what I did once, which was command the simulator, while 
wondering why the spacecraft was not responding. There's only one 
thing worse — commanding the spacecraft while viewing simulated 
data. Design this “feature” out. 


A Telemetry and Command Simulator is a simple stimulus-response 
unit. This is adequate at a low level, but we would like to have a 
software spacecraft, that models dynamics, electrical power, data 
flow, and others. This means the simulation also has to include a lot 
of additional models, such as the Sun, the Earth, the moon, the star 
field, etc. The simulation can be evolved over time and off-the-shelf 
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models are available for many of these functions. 


Ranging 


Ranging is used for position and velocity determination. Basically, 
you transmit a code that is returned and timed by the ground station. 
It is used orbit determination and updating of the onboard model. 


NORAD, the North American Aerospace Command, based in 
Colorado, tracks all detectable orbital entities, from large satellites 
to space junk, zombie-sats, and the larger pieces of debris, as well as 
asteroids. 


NORAD puts all this up on a website for your convenience, in a 
standard format called the “two-line element” (TLE). This contains 
the Keplerian orbital elements, the set of data describing the orbit of 
anything around the Earth, for a given point in time (epoch). It is a 
legacy format form the 1960's, that still works. It includes two data 
items of 80 ASCII charters each (an IBM punch card format). 


Here is the format and contents of Line 1 (courtesy, Wikipedia). 


Field Columns Content 


1 1 Line number 

2 3-7 Satellite number 

3 8 Classification (U = unclassified) 

4 10-11 =‘ Internat. Designator, last two digits of launch year 
5 12-14 Launch number of teh year 

6 15-17 Place of launch 

‘ 19-20 Epoch, last two digits of year 

8 21-32 Epoch, day of year, and fractional portion of day 
9 34-43 First Time Derivative of the Mean Motion 


divided by two 

10 45-52 Second Time Derivative of Mean Motion divided 
by six (decimal point assumed) 

11 54-61 BSTAR drag term, (decimal point assumed) 

12 63 number 0 

13 65-68 element set number, incremented for new TLE 
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14 69 Checksum, modulo 19 


Here is the format of line 2: 


Field Columns Content 


1 1 Line number 

2 3-7 Satellite number 

3 9-16 Inclination (degrees) 

4 18-25 Right ascension of the ascending node (degrees) 
5 27-33 Eccentricity (decimal point assumed) 

6 35-42 Argument of perigee (degrees) 

7 44-51 Mean Anomaly (degrees) 

8 53-63 Mean Motion (revolutions per day) 

9 64-68 Revolution number at epoch (revolutions) 


— 
we 


69 Checksum (modulo 10) 


Need your data? Get an account with spacetrack.org, and get it on 
line. 

You can also use this service: 
http://www.celestrak.com/NORAD/elements/ 


Need to watch out for debris? Go here: 
http://satellitedebris.net/Database/ 


Other functions provided by the Control Center include orbit 
determination and control. These can also be provided to the control 
center as a service. For orbit adjustments, or maneuvers, it is 
essential to know the parameters of the starting point, the current 
orbit. This is usually done by ranging. Measuring the time of flight 
for multiple samples gives a good representation of the position and 
velocity. Also, if the spacecraft can use GPS services, this can give a 
good cross check. 
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In Earth orbit, sometimes the spacecraft must be boosted, because 
the orbit has decayed due to atmospheric effects, which are small but 
cumulative. The amount of energy to be added by the propulsion 
system is calculated, and the spacecraft is oriented to put the thrust 
vector in the right duration. After the maneuver, the orbit is checked 
again, and adjusted as required. 


For spacecraft going somewhere else from Earth orbit, the process is 
similar. Standard transfer orbit geometries are used, with the overall 
plan worked out years before launch, For a Mars lander, for 
example, it is a simple task of hitting a moving target from a moving 
platform, and getting to the right place at the right time, in the 
future. Again, after orbit changing operations, the actual achieved 
orbit or trajectory is checked, and adjusted as required. For missions 
to the outer planets, complicated maneuvers can use the Sun or other 
planets along the way to provide a “gravity boost” to the spacecraft. 
These, again, are calculated years in advance, and executed from the 
control center. 


We should stop here and examine frames of reference. These are 3- 
dimensional Newtonian references, that we can compare our 
spacecrafts orientation, with regards to. There are many possible 
frames of reference, some stationary, some moving. For example, 
we might choose a frame at the center of the Earth, called the Earth 
centered (or geocentric) inertial frame. This is stationary with 
respect to the Earth, and we can calculate the satellite's position with 
respect to this frame. We can also assume the surface of the Earth 
rotates and wobbles a bit with respect to this frame. So, if we want 
to know when the spacecraft can view, say, Madrid, we calculate the 
position of the spacecraft and Madrid, in this frame of reference. 
There is also a solar-based frame, situated in the Sun. This is useful 
for interplanetary mission. The geocentric inertial frame moves with 
respect to the Sun's inertial frame. If we are in orbit around Mars, we 
would used a Mars-centered inertial frame. It is a similar case for the 
other planets. In any frame of reference, we locate the spacecraft in 
three dimensions, with three coordinates, x, y, z, with respect to the 
zero-point, or origin of the frame. It is also useful to know the 
spacecraft's velocity (in three dimensions) with respect to the frame. 
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There is also a Galactic frame. 


Anomaly and emergency contingency operations 


In a problem scenario onboard the spacecraft, the first line of 
defense is the onboard computer and its software. In fact, the ground 
my not even be aware of the problem for hours, in the case of 
missions to the outer planets. The onboard system has the interfaces, 
and, ideally, the pre-arranged solution to the problem. If transmitter 
A fails, turn it off, and turn on B. In the Control center, the 
operations team has to rely on telemetry (or the lack of it) to 
diagnose the problem, and come up with a procedure to fix it, and 
the mission. No pressure. Ideally, an inclusive list of failure 
scenarios have been postulated, and corrective actions defined. 
Failing that, we have a hugely expensive, amazingly complex 
system in a extreme environment to diagnose and fix over a limited 
bandwidth link. Here, the most senior and knowledgeable operations 
personnel are called in to the control center. Originally, all fault 
repairs and workarounds would be determined in the control center, 
and uplinked to the spacecraft. Now, better onboard computers are 
tasked with the initial part of that job, with the control center as 
backup. There are on the scene of the problem. 


Modeling 


A solar model and an atmospheric model are useful, particularly in 
calculating satellite lifetime. The sun is the major driver of the 
Earth's atmosphere, and the residual atmosphere at low Earth orbit 
affects spacecraft due to drag. In sunlight, the atmosphere boils up, 
and drag increases. 


Orbit calculations can be supported in the control center, or done by 
a support facility. Simple modeling tools such as STK (Satellite Tool 
Kit) can be used. NASA-GSFC has an Open source tool called 
ODTBX. For navigation, or orbit adjustment, we must first know 
the existing orbit, and the desired orbit. The tools will allow us to 
explore the optimum transfer orbit. We might want to minimize orbit 
adjust time, or select the most efficient transfer maneuver in terms of 
fuel expended. Theses are complex calculations, but can easily be 
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hosted on standard laptop machines. 


Another useful thing to calculate is the ground track of the orbiting 
spacecraft. This is useful for coordination with ground stations, and 
to see a downward looking instrument's footprint. 


Maintaining a thermal model of the spacecraft can lead to useful 
insight into cooling system performance, and can help to avoid 
extreme temperatures. 


A power/energy model is useful to make sure the spacecraft batteries 
are always staying charged. In some cases, operations must cease 
until the batteries are charged. 


FMEA 


The failure modes and effects analysis is an engineering tool that is 
applied during the design and testing process of a system. In this 
approach, we postulate failure modes, and analyze their impact on 
the system performance. The possible failure modes are examined to 
confirm their validity. Then, the possible failures are prioritized by 
severity and consequences. The goal is to identify and eliminate 
failures in the order of decreasing severity. 


The FMEA approach can actually start at the Project conceptual 
phase, and continue throughout the project life-cycle. It can (and 
should) be applied to modifications to existing projects. The origins 
of the FMEA approach were during World War-II, by the U. S. 
Military. After the war, the approach was adopted by the aviation 
(aerospace) and automotive industries. 


The FMEA analysis requires a cross-functional team, consisting, as 
applicable of hardware and software engineers, manufacturing, 
Quality Assurance, test engineers, reliability engineers, parts, and, 
ideally, the customer. 


The process involves identifying the scope of the project, defining 
the boundaries and the desired level of detail. Then, the system (or 
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project) functions are identified. Each function is analyzed to 
identify how it could fail. For each of these failure cases, the 
consequences are noted. These range from no effects to catastrophic. 
Formally, the consequences are rated on a scale of | to 10, with 1 
being insignificant to 10, catastrophic. The root cause is then 
determined for each consequence, starting with the 10's. Software 
tools are available to support this analysis process. 


Once the causes are determined, the controls are defined. Controls 
prevent the cause from happening, reduce the probability of 
happening, or detect the failure in time for correction to be applied. 
For each control, then, a detection probability rating is calculated (or 
estimated), again on a scale of 1-10. Here, 1 indicates that control is 
certain, and 10 indicates that the solution will not work. By 
definition, critical characteristics of the system have a severity of 9 
or greater, and have an occurrence and detection rating of greater 
than 3. 


A Risk Priority Number (RPN) is calculated, which is severity times 
occurrence time detection (ratings). This measure is used to rank 
failure modes in the order in which they are to be addressed. Of 
course, some of these rankings are not measurable, but the result of 
good engineering guesses. From an FMEA, you can develop 
contingency plans, adjust to the identified failure scenarios. It is 
always good to have a Plan B. Also C, D, E....... 


Mission planning & scheduling 


A major activity in the Control Center involves mission planning 
and scheduling of resources. This results in a daily timeline of 
activities. Contingency plans and re-plans are also produced. The 
Mission plans are very detailed, and there is usually one or more 
mission planners full time. No good plan “they say” survives first 
contact with reality. 


Flight dynamics tools 


Flight Dynamics includes attitude and orbit determination and 
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control. GSFC's General Mission Analysis Tool (GMAT) is available 
as free and open source software, under the NASA Open Source 
Agreement. The tool provides the ability to model and optimize 
spacecraft trajectories. The domain can be LEO, lunar, 
interplanetary, or deep space. 


The spacecraft has to know its orientation with respect to an inertial 
frame of reference. We use the word “orbit” to describe the 
spacecraft's position and velocity. It used to be the case that a 
separate facility would use the tracking data to calculate the orbital 
parameters, and forward these to the Control Center. Later, the 
Control Centers generally took over this function. We need not only 
the parameters of the orbit as its exists now, but what it will be in the 
future. This is the function of orbit propagation. We are limited in 
how far into the future we can predict the orbit, due to data 
limitations, perturbations that affect the spacecraft, and not having a 
closed form solution. 


If the spacecraft uses magnetic torquer bars to push against the 
Earth's magnetic field for attitude adjustment or momentum 
unloading, we need a map of the Earth's magnetic field onboard, 
particularly, the orientation of magnetic north to “north” in the 
inertial frame of reference. 


Generally, the attitude of a spacecraft is described as a vector in a 
frame of reference that is body-centered in the spacecraft. We can 
use three rotational parameters to describe the spacecraft;s attitude 
with respect to this frame. These are generally referred to as roll, 
pitch, and yaw, derived from aircraft. Keep in mind, the body-centric 
frame we are using is moving with the spacecraft, relative to the 
Earth Centered frame. We use Newtonian rigid-body dynamics. This 
is a good approximation, unless the spacecraft has a lot of fuel 
onboard, in which case it does not act as a rigid body. 


Roll indicates a rotation about the velocity vector, the direction of 
motion. Pitch is a rotation up and down, with respect to the velocity 
vector. Yaw is a left-right rotation about the velocity vector. It makes 
more sense in an aircraft, with wings. 


There is another entity that is sometimes used for attitude, called 
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quarternions. These are 4-unit vectors (as opposed to 3-unit roll- 
pitch-yaw), so they contain redundant orientation, but are a little 
easier to calculate, Keep in mind, we can rotate in 2 or 3 directions 
at the same time. So, quarternions, invented in 1843, are used to 
calculate and describe complex three dimensional rotations. 


Essentially, the quarternion is a vector in the inertial space, pointing 
in a direction described by the dimensions along the three axes. 
Then, a fourth parameter describes a rotation around that vector. 


We should mention Euler angles. These are used to describe the 
rotation of an object with respect to a rigid frame of reference. If we 
use the spacecraft body-centric frame, the Euler angles correspond 
to roll, pitch, and yaw. 


It is fairly easy to translate from quarternions back and forth to Euler 
angles. This is left as an exercise for the student. 


If the orbit of the spacecraft is below that of the GPS satellites, it can 
use the GPS data for position and orientation information, the same 
as we do on the surface of the Earth. The constellation of GPS 
satellites orbits at slightly more than 20,000 kilometers, and thus 
serves the LEO community 


Training 


A major role of the Control Center is to train operations personnel. 
Before launch, and during periods when the spacecraft is not in view 
of a ground station, the control center can be with a spacecraft 
simulator to train operations crews for both normal and contingency 
situations. 


Off-line analysis & trending; performance 
assessment 


One role that can be done in the Control Center's back-room is 
analysis and trending of the telemetry data. This is not a real-time 
task, and can be done as a background task. This leads to 
assessments of the spacecraft subsystems performance, and 
identifies trends, such as battery degradation and decreased thermal 
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performance. These are usually gradual effects, and don't require up- 
to-the-moment real-time attention. 


NASA GSFC's Integrated Trending and Plotting (ITPS) tool is an 
example. It implements data retrieval, filtering, and reporting 
functions. It has a remote web interface, and is pc-based. 


Calibration is another engineering task, As the mission goes 
progresses, equipment ages, and previously calibration curves 
derived from testing need updating 


Data Archiving 


Data archiving of all incoming data is done in the control center, 
although this now uses COTS database tools. Off-site data 
repository's may be used. It is important to have sufficient 
workstations in the control center to allow playback of archived 
telemetry if desired. 


Support 1&T 


The same Control Center that will support the Mission can be used 
earlier to support Integration and Test. Not all of the functionality is 
required at this stage. The advantages of this approach are that the 
Control Center software and databases will be validated, the 
operations team can gain experience, and the system can be evolved, 
using lessons-learned. Keep in mind, the primary users during the 
I&T phase are test engineers, not Operations Personnel. This 
approach also avoids a dual develop effort. 


Science Data Processing 


Generally, science (instrument) data is stripped out in the control 
center, and sent to a specialized science data processing data. It is 
common for it to be archived with all other telemetry in the control 
center, but there will also be a science data archive. Most of the 
time, quick-look capability is provided. 
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NASA Data Processing Levels 


NASA Earth Data products are processed at various levels ranging 
from Level 0 to Level 4. Level 0 products are raw data at full 
instrument resolution. At higher levels, the data are converted into 
more useful parameters and formats. Instruments may produce data 
at any of these levels. This is the domain of NASA's Earth 
Observing System Data and Information System (EOSDIS), a large 
data processing facility dedicated to Earth Science at GSFC. 


Processing Levels Definition 


0 Reconstructed, unprocessed instrument and payload data at 
full resolution, with any and all communications artifacts (e. g., 
synchronization frames, communications headers, duplicate data) 
removed. 


la Reconstructed, unprocessed instrument data at full 
resolution, time-referenced, and annotated with ancillary 
information, including radiometric and geometric calibration 
coefficients and georeferencing parameters (e. g., platform 
ephemeris) computed and appended but not applied to the Level 0 
data (or if applied, in a manner that level 0 is fully recoverable from 
level la data). 


1b Level la data that have been processed to sensor units (e. g., 
radar backscatter cross section, brightness temperature, etc.); not all 
instruments have Level 1b data; level 0 data is not recoverable from 
level 1b data. 


2 Derived geophysical variables (e. g., ocean wave height, soil 
moisture, ice concentration) at the same resolution and location as 
Level 1 source data. 


3 Variables mapped on uniform spacetime grid scales, usually 
with some completeness and consistency (e. g., missing points 
interpolated, complete regions mosaicked together from multiple 
orbits, etc.). 
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4 Model output or results from analyses of lower level data (i. 
e., variables that were not measured by the instruments but instead 
are derived from these measurements). 


Early orbit checkout. 


Typically, the Control Center is the primary user gateway to the 
spacecraft. It may generate the data products for the end users of the 
system. In the engineering case, this is the downlinked spacecraft 
health and status information. The the spacecraft is carrying one or 
more science instruments, this data is usually passed along to a 
science data processing and archive center. There can be a high level 
of automation for routine operations, like scheduled updates, and 
more directed operations for anomalies. An example of a routine 
operation that can easily be automated is consumables tracking. 


Multiple Control Centers provide redundancy and geographical 
diversity. It is possible to have a generic Control Center, that is 
software configurable for different missions on demand. This 
depends heavily on flexibility of the configuration, and adherence to 
standards. 


Constellation support 


In many cases, the satellite control center handles a constellation of 
multiple spacecraft. This includes the GPS constellation, the weather 
satellite system,s TDRSS, and a number of commercial 
communications satellites, providing data service world-wide. 


Managing a constellation adds to the complexity. Even if each 
spacecraft is built to the same plan, different spacecraft, launched at 
different times, and having differing times on-orbit, need customized 
attention. The most important aspect is to have a unique identifier, 
so you know which spacecraft you're talking to. 


An approach to Constellation control centers can involve a hierarchy 
of a master control center and with multiple space assets to control, 
or a peer network of individual control centers, that also provides a 
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built-in redundancy and backup. A backup control center is useful 
not only for anomalies at the primary center, but also to allow for 
maintenance and upgrade of the primary center, and for personnel 
training and certification. 


A major constellation is NOAA's Polar and Geostationary weather 
and environmental satellites. The USAF operates the Global 
Positioning System (GPS) Constellation. 


Constellations of communication satellites are used for commercial 
ventures such as DishNetwork, a satellite TV provider, and Iridium 
and GlobalStar, communications constellations. 


The USAF maintains a world-wide satellite control network. The 2™ 
Space Operations Squadron in Colorado is typical of the units 
involved in constellation operations. The system has been in 
existence for decades, starting in the mainframe era of the 1970s, 
transitioning to the client-server architecture, and being modernized 
to pe and server architecture. Extensive training for operators is 
provided. 


An ongoing debate in the optimum architecture for multi-satellite 
control is between a centralized design, and a distributed 
architecture. Centralized is the legacy approach. Distributed takes 
advantage of advances in networking and abstraction. In the 
distributed approach, multiple ground stations and control centers 
are linked by existing terrestrial data communication resources. 


The distributed architecture scales more freely, with computation, 
storage, and communications resources being added as demand 
increases. High system reliability and security can be maintained 
from industry best practices. The scalable, distributed technology 
has been driven by large data-centric organizes such as Google, and 
retailers such as Amazon, as well as social media sites such as 
Facebook and Utube. These do not meet military-grade security, of 
course, but that can be addressed. 


Another advantage of the distributed approach is dynamic allocation 
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of resources, having (and paying for) resources when you need 
them, not all the time. The system provides mission safety 
simultaneously with cost effectiveness. A metric of interest is the 
staff to spacecraft ratio. If domain-skilled staff can be shared among 
the constellation, yet be brought together in the case of anomalies, 
personnel costs can be contained. Distributed approaches give 
economy of scale. 


The same information for each spacecraft in a homogeneous 
constellations provides summaries of critical cross-platform 
information. If we just had a failure on one spacecraft, we will look 
for that to happen on others. A merged database, allows for trending 
information to flow forward. As constellations age, the individual 
members age and fail at different rates. From trending data on early 
failures, the remaining spacecraft can be monitored especially for 
known failures and degradation. 


The T&C handbook 


The Telemetry & Command Handbook is a crucial document for the 
Control Center. It contains and defines each command, and each 
telemetry point for the uplink and downlink. It is now commonly a 
database. Compiling the T&C handbook begins early in the project, 
and continues to be updated during flight. It must be a 
configuration-controlled document. Now it is common to keep the 
Handbook in electronic form, under configuration control. 


Ground Segment 


The Ground Segment consists of the antennas, RF receivers and 
transmitters, and communication lines to the Control Center. The 
Ground segment is the link between the control center, and the 
satellites. All data are archived at the ground segment, in case of 
communication interruption with the control center. Before high 
speed data lines, this was done locally on magnetic tape, which 
would later be shipped to an archive. 


Originally, the tracking stations were linked with the GSFC facility 
over leased dedicated landlines. Data communications was provided 
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by NASCOM, using 4,800 bit blocks. Today, almost all of the traffic 
moves over the Internet. 


Near-Earth Network 


The Near Earth Network (NEN) communicates with near-Earth 
orbiting satellites (out to Lunar orbit). It uses the NASA ground 
stations. There are two stations in Florida, in proximity to the 
Kennedy Center launch site, at the launch facility at Wallops Island, 
Virginia, and at the McMurdo Base in Antarctica. In addition, other 
commercial ground stations can be used, under contract to NASA. 
Goddard Space Flight Center in Greenbelt, Maryland, manages the 
NEN, which was formally know as the Ground Network (GN). The 
dish antennae of the GN range from 34 meters to 70 meters in 
diameter. 


Space Network 


The Space Network (SN) dates back to the early 1980's, when 
NASA introduced a constellation of satellites to replace the ground 
tracking stations. 


The Tracking and Data Relay Satellites, in geosynchronous orbit, are 
the Space Segment (SS) of the SN. They implement 
communications between to low Earth orbiting spacecraft, and one 
of the TDRSS ground segments. The ground segment units are 
located at White Sands, New Mexico, and on Guam Island, in the 
Pacific. White Sands also serves as the controlling station for the 
TDRS spacecraft. The TDRS network was declared operational in 
1989. STDN stations at Wallops Island, Bermuda, Merritt Island 
(FL), Ponce de Leon (FL), and Dakar, Senegal, remained 
operational. 


The Tracking & Data Relay Satellite System is over 30 years old, 
and is being refreshed with new technology. The Space Segment 
has spare assets in orbit in case of failure. 
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Deep Space Network 


NASA's Deep Space Network consists of three sites spaced around 
the planet. It supports deep space missions for NASA and other 
entities. It is managed by the Jet Propulsion Lab (JPL) in Pasadena, 
California.. The nearest station to JPL is at Goldstone, in the desert 
to the east. Two other stations, in Spain and Australia are spaced 
about 120 degrees apart on the globe from Goldstone. The DSN 
started operations in the 1960's, with teletype communications with 
the Pasadena facility. The DSN is heavily used, but can provide 
backup to the Space Network for contingencies. 


Cubesat T&C 


Cubesats are low cost, University-class missions and the Cubesat 
community needs low cost telemetry and command support. One 
approach is provided by Satnogs (satnogs.org), which is a low cost, 
cooperative satellite ground station and network. It uses a modular 
architecture , with a global management architecture that allows for 
remote operation of multiple, geographically-dispersed ground 
stations. It is based on open source hardware and software. 


There is a large number of compatible ground stations around the 
world, operated by schools or individuals. These are all tied 
together, over the Internet. Each agrees to handle other's telemetry 
and commanding. An example installation is at MakerFaire in New 
York. It features a yagi antenna for 144.8 MHz, and a helical 
antenna for 437 MHz. 


The Satnogs website provides all the information for building the 
necessary antenna, the ground receiver, and the Internet connection, 
as well as the software. The tracking system for the antennas is 3-D 
printable, and driven by stepper motors. The baseline configuration 
includes the BeagleBone Black or the TP-Link TL-WR703N ($25.) 
single-board computer. Running Debian Linux or OpenWrt, it 
supports all ground station functionality (status, tracking, signal 
receiving and processing) over LAN or WiFi for extreme mobility or 
remote operation. (https://satnogs.org) 
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The Global Educational Network for Satellite Operations (Gemso) is 
a software standard, started at ESA, with a series of ground stations 
around the world. It was developed for Cubesats. It was started in 
2007. 


There is a Ground Station Server, and a Mission Control Client in 
the software architecture. Additionally, there is an Authentication 
Server, to restrict access to registered satellites, and authorized 
users. The Amateur Radio Community, worldwide, provides the 
Radio Frequency (RF) equipment and services. Ground stations 
operate 24x7. The Genso software is written in Java. 


Ref: 
http://m.esa.int/Education/Global_Educational_ Network_for_Satelli 
te_Operations 


Deep Space Comm Relays 


There is an evolving orbital infrastructure around Mars, which 
simplifies the communications problem for surface-based Rovers. 
They communicate with the (Mars) orbital communication satellite, 
which handles the long-haul communications to and from Earth. For 
extended periods of time, Earth and Mars are on opposite sides of 
the Sun, and communication between the planets is not possible. 


Back Side of the Moon 


So close, yet so far away. Any payload or rover on the lunar 
backside is permanently out of touch with Earth, because the moon 
is in tidal lock, and one side always faces Earth. Lunar orbiters are 
out of communications with Earth for somewhat less than a half 
orbit. This can be solved with a communications relay satellite in 
lunar polar orbit. The moon does wiggle a bit, less than 50% of the 
surface is permanently out of touch. 


If we could precess the lunar comm relay spacecraft so that the orbit 
remains normal to the Earth-Moon line, it would be ideal. This 
might involve excessive propellant expenditure, lowering the 
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mission life. 
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Infrastructure 


This section discusses the support structure for the mission control 
center. This includes the computation and communication assets. A 
reliable source of power is also essential. For 24x7 operation, such 
as required in early on-orbit checkout, human needs must be 
considered, such as a snack bar and places to catch a quick nap. 


The incoming telemetry data and the outgoing uplink commands use 
serial data links to and from the control center, to an antenna facility. 
The command (uplink) rate is generally low and usually infrequent. 
The data downlink volume can be very large and continuous. 


Security 


The Control Center has issues of security, both operational and data. 
First, it needs to be a controlled access facility. Only authorized 
personnel should be in the MCC. But don't forget virtual users. Can 
the control center computers be hacked into? What ports and 
backdoors exist in the implementation? Best practices from the 
Computer/Network Security Industry can be applied. 


The Control Center must quickly act quickly to identify and react to 
cyberattacks. These might be phishing expeditions to steal data, 
malicious attacks to gain control of space assets, or denial of service 
attacks. A good penetration-testing of the facility is called for. There 
should be a permanent Security Officer for data, with the 
responsibility for data and operations. 


Open Source versus Proprietary 


This is a topic we need to discuss before we get very far into 
software. It is not a technical topic, but concerns your right to use 
(and/or own, modify) software. It’s those software licenses you click 
to agree with, and never read. That’s what the intellectual property 
lawyers are betting on. 


Software and software tools are available in proprietary and open 
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source versions. Open source software is free and widely available, 
and may be incorporated into your system. It is available under 
license, which generally says that you can use it, but derivative 
products must be made available under the same license. This 
presents a problem if it is mixed with purchased, licensed 
commercial software, or a level of exclusivity is required. Major 
government agencies such as the Department of Defense and NASA 
have policies related to the use of Open Source software. 


Adapting a commercial or open source operating system to a 
particular problem domain can be tricky. Usually, the commercial 
operating systems need to be used “as-is” and the source code is not 
available. The software can usually be configured between well- 
defined limits, but there will be no visibility of the internal 
workings. For the open source situation, there will be a multitude of 
source code modules and libraries that can be configured and 
customized, but the process is complex. The user can also write new 
modules in this case. 


Large corporations or government agencies sometimes have 
problems incorporating open source products into their projects. 
Open Source did not fit the model of how they have done business 
traditionally. They are issues and lingering doubts. Many Federal 
agencies have developed Open Source policies. NASA has created 
an open source license, the NASA Open Source Agreement 
(NOSA), to address these issues. It has released software under this 
license, but the Free Software Foundation had some issues with the 
terms of the license. The Open Source Initiative 
(www.opensource.org) maintains the definition of Open Source, and 
certifies licenses such as the NOSA. 


The GNU General Public License (GPL) is the most widely used 
free software license. It guarantees end users the freedoms to use, 
study, share, copy, and modify the software. Software that ensures 
that these rights are retained is called free software. The license was 
originally written by Richard Stallman of the Free Software 
Foundation (FSF) for the GNU project in 1989. The GPL is a 
copyleft license, which means that derived works can only be 
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distributed under the same license terms. This is in distinction to 
permissive free software licenses, of which the BSD licenses are the 
standard examples. Copyleft is in counterpoint to traditional 
copyright. Proprietary software “poisons” free software, and cannot 
be included or integrated with it, without abandoned the GPL. The 
GPL covers the GNU/linux operating systems and most of the 
GNU /linux-based applications. 


A Vendor’s software tools and operating system or application code 
is usually proprietary intellectual property. It is unusual to get the 
source code to examine, at least without binding legal documents 
and additional funds. Along with this, you do get the vendor support. 
An alternative is open source code, which is in the public domain. 
There are a series of licenses covering open source code usage, 
including the Creative Commons License, the gnu public license, 
copyleft, and others. Open Source describes a collaborative 
environment for development and testing. Use of open source code 
carries with it an implied responsibility to “pay back” to the 
community. Open Source is not necessarily free. 


The Open source philosophy is sometimes at odds with the rigidized 
procedures evolved to ensure software performance and reliability. 
Offsetting this is the increased visibility into the internals of the 
software packages, and control over the entire software package. 
Besides application code, operating systems such as GNU/linux and 
bsd can be open source. The programming language Python is open 
source. The popular web server Apache is also open source. 


ITAR 


Systems that provide “satellite control software” are included under 
the International Trafficking in Arms (ITAR) regulation, as the 
software is defined as “munitions” subject to export control. The 
Department of State interprets and enforces ITAR regulations. It 
applies to items that might go to non-US citizens, even citizens of 
friendly nations or NATO Partners. Even items received from Allies 
may not necessarily be provided back to them. Software and 
embedded systems related to launch vehicles and satellites are given 
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particular scrutiny. The ITAR regulations date from the period of the 
Cold War with the Soviet Union. Increased enforcement of ITAR 
regulations recently have resulted in American market share in 
satellite technology declining. A license is required to export 
controlled technology. This includes passing technical information 
to a foreign national within the United States. Penalties of up to 
$100 million have been imposed for violations of the ITAR 
Regulations, and imprisonment is also possible. Something as 
simple as carrying ITAR information on a laptop or storage medium 
outside the US is considered a violation. ITAR regulations are 
complex, and need to be understood when working in areas of 
possible application. ITAR regulations apply to the hardware, 
software, and Intellectual Property assets, as well as test data and 
documentation. 


Internet, and loT 


The Internet is a global data highway, and there is even an 
Interplanetary Internet. The concept dates from early efforts in data 
transmission in the 1970's, and works quite well. Satellite data can 
be collected at any downlink station, and sent to a satellite control 
center over the Internet. Similarly, commands can be sent for uplink. 
Similarly, uplinks to the spacecraft can be transmitted over the 
Internet, with proper security protocols in place. Data privacy may 
also be a concern. The Internet uses TCP/IP protocols, and 
spacecraft generally use CCSDS protocols. 


The Internet grew out of the DoD sponsored ARPAnet, which was 
modeled on AlohaNet, invented to allow data communications 
among the Hawaii Islands. 


Packets are bundled data, handled identically by the transmission 
system. Think of them as containers of data, in the same way that 
standardized containerized freight revolutionized global freight 
delivery. The standard container is compatible with rail, road, and 
water transportation. The packet, with its data content moves by 
radio, or optical fiber, landline, satellite link, and more. Besides the 
information (“payload”), the packet contains control information 
such as receiver address, sender address, packet number (for 
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payloads spread across packets), possibly error detection and 
correction information, etc. In the seven layer network model, 
packets are data units at level three. The data payload of a packet 
can be variable length. 


CCSDS Packets are used on near-Earth and Deep Space 
communication links. These have more rigorous error detection and 
correction schemes. The data length is variable, and can be from 7 to 
65,542 bytes, which includes the header. Packet sizes are fixed 
length. The transmission of packets is via data frames, which are 
also fixed length. The frame also contains control information. The 
data frames are the legacy component of the space communication 
segment. 


We can have universal world-wide connectivity, using the .net 
framework, which is free and open source software. Net framework 
allows a device to be a http client. It can access data, provide data, 
and access services. It handles the hard part with code for requests 
and the socket interface, and is available as off-the-shelf libraries. It 
is also available per-programmed into flash memory, and provides 
access to a huge ecosystem of network resources. 


So now, not only people with desktops, laptops, tablets and phone 
can populate the Internet, along with the server/cloud architecture, 
but devices can as well. This concept of IoT kicked off around 
2014, but has seen tremendous growth. It is estimated that there are 
more “things” on the Internet, than people. These are event driven. 
There is some concern this whole structure will become non- 
deterministic, even practically. It's just too complex, and feeding 
upon itself. The applications are limited only by imagination. 
Spacecraft and their monitoring and control centers can be items on 
the IoT. 


We need to architect and implement the IoT carefully. At least as 
long as we are in charge. It can provide a whole new world-wide 
platform for cyber-attacks. How can it be managed? Can it be 
managed? It is a rapidly evolving system, with positive feedback. 
There are privacy concerns. Now that this is working, we can't put 
the Genie back in the bottle. We can only hold on, and hope to steer. 
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Does the Internet of Things really need us? 


The Internet of Things is built upon web-accessible embedded 
systems. More and more embedded systems are on the web. This 
allows to integrate cheap embedded devices with ubiquitous web 
services, accessible with wireless technologies. An example is a 
smart electric meters. Smart devices, including satellites, can access 
data, provide data, or access services. 


To make use of this concept, we need uniquely identifiable objects 
such as smart sensors, smart actuators, smart platforms. What is the 
identity scheme? The Uniform Resource Locater (URL) approach 
can be adopted We also need advanced connectivity to the Internet, 
which provides distance-insensitive world-wide connectivity. These 
are large areas of the Earth's surface where the Internet does not 
reach, but satellite links can be used, although this is an expensive 
approach. The polar regions enjoy good satellite communications 
due to a series of polar orbiting spacecraft. 


There may now be more “things” on the Internet than people. There 
is a huge ecosystem of devices, talking to cloud servers, and among 
themselves. This reduce the reliance on people (who needs us 


anyway?). 


Cloud servers allow access to “unlimited”? datasets and resources. 
The latest trend is cloud robotics, where a connected mobile 
platform can offload computational and storage resources by having 
a good communications link. 


Free and open source software and collaborative development 
environments enhance the deployment process. There are standard 
software interfaces for communication protocols. 


File Systems 


A file system provides a way to organize data in a standard format. 
The file system stores the data, and metadata (data about the data) 
such as date, time, permissions, etc. Some operating systems support 
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multiple file systems. 


The important thing to keep in mind about about a file systems is, 
don’t reinvent the wheel! There are many good file systems out 
there, and the provide a compatibility across platforms. Most are 
based on the original disk operating system (dos) model. 


The legacy DOS file structure is built upon linked lists. The 
directory file contains lists of files and information about them. It 
uses a 32-byte entry per file, containing the file name, extension, 
attributes, date and time, and the starting location of the file on disk. 


The File Allocation Table (FAT) is a built map of allocated clusters 
on the disk. A cluster is the default unit of storage. It’s size is a 
trade-off between efficiency of storage, and efficiency of access. A 
size of 256 bytes to 1024 bytes worked well in the early days. Two 
copies of the FAT are kept by the system, and these are on fixed 
locations of the storage media. 


A directory file has entries for all of the files on the disk. The name 
of the file is in 8.3 format, meaning an 8 character file name, and a 
3-character extension. The extension tells the type of the file, 
executable program, word processing, etc. By DOS convention, 
when a file is erased, the first character of the name is changed to 
the character E5'°. The data is not lost at this point. If nothing else 
happens in the mean-time, the file can be un-erased, and recovered. 
However, the E5 signifies the space the file occupied is now 
available for use. 


Various file attribute bits are kept. The file can be marked as read- 
only, hidden, reserved system type, and bits indicate a directory 
field, a volume label (name of a storage volume, like, “disk1’’), and 
whether the file has been archived (saved). There is a 16-bit date 
code in the format (year-1980)*512 + month * 32 + day. (thought 
exercise — when do we have a problem?). The starting cluster 
number in a directory is kept as a word value. This limits us to 216 
clusters. 
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The FAT was originally 12-bits, but later extended to 16. Eventually, 
this was extended to 32-bits for Windows, and is no longer DOS 
compatible. Entries in the FAT map the clusters on the storage 
media. These indicate used, available, bad, and reserved clusters. 


Databases 


Databases are useful for organizing data, and making it easy to 
access. The are many excellent database products, usually based on 
the Structured Query Language (SQL) model. The incoming 
telemetry and outgoing commands are stored, time tagged. There is 
no need to re-invent the wheel again here. Commercial databases 
(and some come in open source versions) scale well and provide the 
security and query features needed. 


Standards 


There are many Standards applicable to control centers. These range 
from general computer standards to domain-specific standards. Why 
should we be interested in standards? Standards represent an 
established approach, based on best practices. Standards are not 
created to stifle creativity or direct an implementation approach, but 
rather to give the benefit of previous experience. Adherence to 
standards implies that different parts will work together. Standards 
are often developed by a single company, and then adopted by the 
relevant industry. Other Standards are imposed by large customer 
organizations such as the Department of Defense, or the automobile 
industry. Many standards organizations exist to develop, review, and 
maintain standards. 


Standards exist in many areas, including hardware, software, 
interfaces, protocols, testing, system safety, security, and 
certification. Standards can be open or closed (proprietary). 


Hardware standards include the form factor and packaging of chips, 


the electrical interface, the bus interface, the power interface, and 
others. The JTAG standard specifies an interface for debugging. 
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In computer architecture, the ISA specifies the instruction set and 
the operations. It does not specify the implementation. Popular 
ISA’s are x86 (Intel) and ARM (ARM Holdings, LTD). These are 
proprietary, and licensed by the Intellectual Property holder. 


In software, an API (applications program interface) specifies the 
interface between a user program, and the operating system. To run 
properly, the program must adhere to the API. POSIX is an IEEE 
standard for portable operating systems. 


There are numerous Quality standards, such as those from ISO, and 
Carnegie-Mellon’s CMM (Capability Maturity Model). CMM 
defines five levels of organizational maturity in a company or 
institution, and is independently audited. 


Language standards also exist, such as those for the ANSI c and Java 
languages. 


Networking standards include Transmission Control 
Protocol/Internet Protocol) TCP/IP, the CAN bus from Bosch, and 
TEEE-1553 for avionics. The X.25 standard is a data link layer 
protocol for the Internet, and AX-25 is a similar standard for 
amateur radio users of packet radio. 


The ISO-9000 standard was developed by the International 
Standards Organization, and applies to a broad range industries. It 
concentrates on process. It’s validation is based on extensive 
documentation of organization’s process in a particular area, such as 
software development, system build, system integration, and test and 
certification. 


It is always good to review what standards are and could be applied 
to a system, as it ensures the application of best practices from 
experience, and interoperability with other systems. 


The Portable Operating System Interface for Unix (POSIX) is an 
IEEE standard, IEEE 1003.1-1988. The standard spans some 17 
documents. POSIX provides a Unix-like environment and API. 
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Various operating systems are certified to POSIX compliance, 
including BSD, LynxOS, QNX, VxWorks, and others. 


The CCSDS, Consultive Committee on Space Data Standards, has a 
series of International standards for space data systems. There are 
eleven member nations as members. They publish standards in six 
major areas of interest, including 16 for spacecraft onboard 
interfaces. Other standards cover systems engineering, space link, 
and space inter-networking. On their web site, they list 750 missions 
using their defined protocols. 


TCP/IP protocols 


The Transmission Control Protocol and the Internet Protocol enable 
our world wide, and solar-system wide digital communications 
infrastructure. TCP/IP enables end-end connectivity and data 
delivery. There are four layers in the scheme, the link, the internet, 
the transport, and the application layers. Most of the work on 
TCP/IP came from Vint Cerf's work at Stanford University for 
DARPA. There is a vast library of TCP/IP standards and best 
practices. Two of the key architectural principals are defined in the 
architectural document RFC 1122. The RFC, or Request for 
Comment, is the mechanism for reviewing documents by the user 
community. RFC 1132 defines the end-to-end principle, and the 
robustness principal. 


The end-to-end principle has evolved since its its expression put the 
maintenance of state and overall intelligence at the edges, and 
assumed the Internet that connected the edges retained no state and 
concentrated on speed and simplicity. Real-world needs for 
firewalls, network address translators, web content caches and the 
like have forced evolutionary changes in this principle. The 
Robustness principle says "In general, an implementation must be 
conservative in its sending behavior, and liberal in its receiving 
behavior. That is, it must be careful to send well-formed datagrams, 
but must accept any datagram that it can interpret." The second part 
of the principle is almost as important: software on other hosts may 
contain deficiencies that make it unwise to exploit legal but obscure 
protocol features.” These two principles have driven the 
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implementation of the Internet we use today, on Earth, and between 
the planets. TCP/IP defines abstraction layers for network topology 
and data flow among systems. A complete discussion of TCP/IP is 
beyond the scope of this book, but is an important topic in 
understanding how and why modern data communications works the 
way it does. 


IP-in-space 


The use of Internet Protocol for space missions is a convenience, 
and piggy-backs on the large established infrastructure of terrestrial 
data traffic. However, there are problems. A variation of mobile IP is 
used, because the spacecraft might not always be in view of a 
ground station, and traffic through the Tracking and Data Relay 
Satellites involves a significant delay. A hand-off scheme between 
various “cell” sites must be used, and a delay-tolerant protocol. 
However, onboard the spacecraft, the CISCO CLEO router or 
similar may be used for onboard IP traffic. 


Cubesat Space Protocol 


This is a network layer protocol, specifically for Cubesats, released 
in 2010 It features a 32-bit header with both network layer and 
transport layer data. It is written in the c language, and works with 
linux and FreeRTOS. The protocol and its implementation is Open 
source. At the physical layer, the protocol supports CAN bus I2C, 
RS-232, TCP/IP and CCDSDS space link protocol. 


Interplanetary Internet 


Communications between planets in our solar system involves long 
distances, and significant delay. New protocols are needed to 
address the long delay times, and error sources. 


A concept called the Interplanetary Internet uses a store-and-forward 
node in orbit around a planet (initially, Mars) that burst-transmits 
data back to Earth during available communications windows. At 
certain times, when the geometry is right, the Mars bound traffic 
might encounter significant interference. Mars surface craft 
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communicate to Orbiters, which relay the transmissions to Earth. 
This allows for a lower wattage transmitter on the surface vehicle. 
Mars does not (yet) have the full infrastructure that is currently in 
place around the Earth — a network of navigation, weather, and 
communications satellites. 


For satellites in near Earth orbit, protocols based on the cellular 
terrestrial network can be used, because the delays are small. In fact, 
the International Space Station is a node on the Internet. By the time 
you get to the moon, it takes about a second and a quarter for 
electromagnetic energy to traverse the distance. Delay tolerant 
protocols were developed for mobile terrestrial communication, but 
break down in very long delay situations. 


We have a good communications model and a lot of experience in 
Internet communications. One of the first implementations for space 
used a File Transfer Protocol (FPP) running over the CCSDS space 
communications protocol in 1996. 


The formalized Interplanetary Internet evolved from a study at JPL, 
lead by Internet pioneer Vint Cerf, and Adrian Hook, from the 
CCSDS group. The concepts evolved to address very long delay and 
variable delay in communications links. For example, the Earth to 
Mars delay varies depending on where each planet is located in its 
orbit around the Sun. For some periods, one planet is behind the Sun 
from the point of view of the other, and communications between 
them is impossible for days and weeks. 


The Interplanetary Internet implements a Bundle Protocol to address 
large and variable delays. Normal IP traffic assumes a seamless, 
end-to-end, available data path, without worrying about the physical 
mechanism. The Bundle protocol addresses the cases of high 
probability of errors, and disconnections. This protocol was tested in 
communication with an Earth orbiting satellite in 2008 


Fault Tolerant Design 


In this design approach, a system is designed to continue to operate 
properly in the event of one or more failures. It is sometimes 
referred to as graceful degradation. There is, of course, a limit to the 
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number of faults or failures than can be handled, and the faults or 
failures may not be independent. Sometimes, the system will be 
designed to degrade, but not fail, as a result of the fault. Fault 
recovery in a fault-tolerate design is either roll forward, or roll back. 
Roll back refers to returning the system state to a previous 
checkpointed state. Roll forward corrects the current system state to 
allow continuation. Can you recover your platform if it fails, or will 
it be at the bottom of a lake, or achieving terminal velocity as it falls 
through the atmosphere (toward your neighbor's dog house)? 


Redundancy 


Redundancy refers to the technique of having multiple copies of 
critical components. This applies equally to hardware or software. 
This approach increases the reliability of the system. Redundant 
units can be deployed in parallel, such as extra structural members, 
where each single unit can handle the load. This provides what is 
referred to as a margin of safety. An improvement in reliability can 
be achieved by simply adding a second unit in many cases. In 
certain systems that are responsible for safety-critical tasks, we 
might triplicate the critical portion, which, reduces the probability of 
system failure to small, acceptable, levels. 


Of course, if there is a common error in the three units, we have not 
increased our reliability. This situation is referred to as a common 
mode or single point error. Another problem is in the voting logic, 
that makes the decision that an error has been made, and switches 
controllers. At least one satellite launch failed because the voting 
logic made the wrong choice. Redundancy carries penalties in size, 
power, cost, and testing complexity, all of which affect the design. 


Fault isolation allows the system to operate around the failed 
component, using backup or alternative modules. Fault containment 
strives to isolate the fault, and prevent propagation of the failure. 


Systems can be designed to be fail-safe, fail-soft, or can be “melt- 


before-fail.” The more fault tolerance that is built into a system, the 
more it will cost, and the more difficult it will be to test. It is 
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important not to increase the complexity to the point where the 
system is not testable, and is “designed to fail.” Geographic 
diversity is important to support of ongoing missions. This no longer 
requires multiple physical implementations. If the control center is 
virtualized, then a hosting provider can have multiple instances of 
the control center synchronized and running at geographically 
diverse locations. 


Security 


Has your satellite been hacked yet? Is your satellite data being used 
by others without your permission? Are you sure? 


Every system has aspects of security. Satellite control centers 
operate in a hostile world. They are vulnerable to variations of 
hacking, viruses and malware, theft, damage, spoofing, and other 
nasty techniques from the desktop/server world. GPS systems can be 
hacked to provide incorrect location or critical time information. A 
bored teenage hacker in Europe took over the city Tram system as 
his private full-scale railroad, using a TV remote. What about the 
teenager in an internet café is a third-world country. Can he take 
over and play with your satellite? Anytime he wants to. 


Some of these issues are addressed by existing protocols and 
standards for access and communications security. Security may also 
imply system stability and availability. Standard security measures 
such as security reviews and audits, threat analyses, target and threat 
assessments, countermeasures deployment, and extensive testing 
apply to the control center. 


The completed functional system may need additional security 
features, such as intrusion detection, data encryption, and other 
features that are used in large computer installations and network 
facilities. 


Virus and malware attacks on desktops and servers are common, and 


an entire industry related to detection, prevention, and correction has 
been spawned. Attacks on new technology such as cell phones, 
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pda’s, tablets, and GPS systems have happened. Not all of the 
threats come from individuals. Some are large government-funded 
efforts or commercial entities seeking proprietary information or 
market position. Security breaches can be inspired by ideology, 
money, or fame considerations. The CERT (Computer Emergency 
Response Team) organization at Carnegie Mellon University, and 
the SANS Institute (SysAdmin, Audit, Networking, and Security) 
track security incidents. 


Techniques such as hard checksums and serial numbers are one 
approach to device protection. If unused computer ports exist, the 
corresponding device drivers should be disabled, or not included. 
Mechanisms built into the cpu hardware can provide protection of 
system resources such as memory. 


Security has to be designed in from the very beginning; it can’t just 
be added on. Memorize this. There will be a quiz. 


Even the most innocuous platform can be used as a springboard to 
penetrate other systems. It is essential to consider security of all 
embedded systems, be aware of industry best practices and lessons 
learned, and use professional help in this specialized area. 
Virtualization can enhance or detract from security. 


Control Center I/O 


The satellite control center receives spacecraft telemetry and 
tracking information, and sends commands to the spacecraft. 


NASA's Goddard Space Fight Center in Greenbelt, Maryland, has 
been the hub of the space data network since the beginning. In the 
Apollo era, a world-wide system of ground stations providing 
continuous coverage was not yet in existence. NASA supplemented 
their ground stations with a series of tracking ships, to fill in 
coverage gaps. All data came to the basement of the Operations 
Building, 14, at Greenbelt. It was then routed upstairs to satellite 
control centers, or to Houston or Marshall for Manned flights. For 
its interplanetary missions, JPL maintained the Deep Space 
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Network, a set of three very large antennas spaced around the world. 
During launch and near Earth operations, these were supplemented 
by NASA's world-wide set of tracking stations for Earth orbiting 
satellites. 


Goddard operates the Ground Network, getting data from the source 
to the destination, and the Space Network. The Department of 
Defense has its own tracking and data centers, as well as mission 
control rooms. 


Open Source tools for the Control Center 


A list of open source tools for the Control Center can be found here: 
http://wiki.developspace.net/Open_ Source Engineering Tools 


Examples include a Java-based astrodynamics tool, tools for 
Mission Analysis, orbit determination and prediction, spacecraft 
simulation and modeling, a satellite constellation visualizer, a tool 
for solar sails, and more. As will be discussed later on in this book, 
a complete open source control center is available. This is the 
COSMOS product from Ball Aerospace. The author has direct 
hands-on experience implementing a cubesat control center, on a 
laptop, using this toolset. 


Technology Readiness Levels 


The Technology readiness level (TRL) is a measure of a facilitiy's 
maturity for use. There are different TRL definitions by different 
agencies (NASA, DoD, ESA, FAA, DOE, etc). TRL are based on a 
scale from | to 9, with 9 being the most mature technology. The use 
of TRLs enables consistent, uniform, discussions of technical 
maturity across different types of technology. We will discuss the 
NASA one here, which was the original definition from the 1980's. 
It is generally applied to flight hardware, but can be used for the 
associated ground support infrastructure as well. 
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Technology readiness levels in the National Aeronautics and 
Space Administration 


1. Basic principles observed and reported 

This is the lowest "level" of technology maturation. At this level, 
scientific research begins to be translated into applied research and 
development. 


2. Technology concept and/or application formulated 

Once basic physical principles are observed, then at the next level of 
maturation, practical applications of those characteristics can be 
‘invented’ or identified. At this level, the application is. still 
speculative: there is not experimental proof or detailed analysis to 
support the conjecture. 


3. Analytical and experimental critical function and/or characteristic 
proof of concept. 


At this step in the maturation process, active research and 
development (R&D) is initiated. This must include both analytical 
studies to set the technology into an appropriate context and 
laboratory-based studies to physically validate that the analytical 
predictions are correct. These studies and experiments should 
constitute "proof-of-concept" validation of the applications/concepts 
formulated at TRL 2. 

4. Component and/or breadboard validation in laboratory 
environment. 


Following successful "proof-of-concept" work, basic technological 
elements must be integrated to establish that the "pieces" will work 
together to achieve concept-enabling levels of performance for a 
component and/or breadboard. This validation must be devised to 
support the concept that was formulated earlier, and should also be 
consistent with the requirements of potential system applications. 
The validation is "low-fidelity" compared to the eventual system: it 
could be composed of ad hoc discrete components in a laboratory 


TRL's can be applied to hardware or software, components, boxes, 
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subsystems, or systems. Ultimately, we want the TRL level for the 
entire systems to be consistent with our flight requirements. Some 
components may have higher levels than needed. 


5. Component and/or breadboard validation in relevant environment. 


At this level, the fidelity of the component and/or breadboard being 
tested has to increase significantly. The basic technological elements 
must be integrated with reasonably realistic supporting elements so 
that the total applications (component-level, sub-system level, or 
system-level) can be tested in a 'simulated' or somewhat realistic 
environment. 


6. System/subsystem model or prototype demonstration in a relevant 
environment (ground or space). 


A major step in the level of fidelity of the technology demonstration 
follows the completion of TRL 5. At TRL 6, a representative model 
or prototype system or system - which would go well beyond ad 
hoc, 'patch-cord' or discrete component level breadboarding - would 
be tested in a relevant environment. At this level, if the only 
‘relevant environment’ is the environment of space, then the 
model/prototype must be demonstrated in space. 


7. System prototype demonstration in a space environment. 


TRL 7 is a significant step beyond TRL 6, requiring an actual system 
prototype demonstration in a space environment. The prototype 
should be near or at the scale of the planned operational system and 
the demonstration must take place in space. 


The TRL assessment allows us to consider the readiness and risk of 
our technology elements, and of the system. 


TRL's can be applied to hardware or software, components, boxes, 
subsystems, or systems. Ultimately, we want the TRL level for the 
entire systems to be consistent with our flight requirements. Some 
components may have higher levels than needed. The TRL 
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assessment allows us to consider the readiness and risk of our 
technology elements, and of the system. 


Control Center as a Service 


Do we need to own our hardware? Sometimes, yes. Many times, no. 
The main drivers for the Control Center implementation are mission 
safety and cost-effectiveness. A Cloud-based architecture can 
provide economies of scale, with security. After all, your credit card 
transactions are processed in the Cloud now. You can have whatever 
security you wish to pay for. You're not paying for hardware, 
software, or a bricks and mortar facility, but for a service. A Control 
Center is a central gathering place for multiple engineering 
disciplines to come together to support the mission. Can we 
virtualize this functionality, using “the cloud” and “the web”? Yes. 
But in times of crisis, when everything is going wrong, it is best to 
have every one in the same space, and allow direct interaction 
between staff. 


Virtualization 


Virtualization provides a powerful tool for software development, 
testing, security, and operational environments. The Cloud 
architecture provides economy of scale in computing by shared 
resource usage. With virtualization, multiple “guest” operating 
systems can be run simultaneously under control of a “hypervisor.” 
These guest operating systems do not need to all be the same. The 
Hypervisor manages the physical resources of the computer for the 
various guest operating systems, much as the operating systems do 
for the application code. The hardware resources include the central 
processing units, the various hierarchies of memory, and the 
input/output. Virtualization allows for server consolidation. It can 
ease migration and upgrade. Coupled with commodity computing, 
where you don't own the servers, but just rent time on them, a new 
economic model of hosting an operation like a satellite control 
center becomes easier. 


We are talking her of virtualizing machines to support the Control 
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Center Operation. There are two top level approaches to 
virtualization, the Process Virtual Machine, and the System Virtual 
machine. These two approaches differ in the implementation of the 
relationship of the Hypervisor and the operating system(s), with 
respect to the ring model of security. 


A process virtual machine supports a single process. That single 
process provides a virtual model or abstraction of a certain machine 
model. Operating systems cannot operate in this environment 
unmodified, as they do not see the actual hardware. A good example 
is the Java Virtual Machine. 


The Hypervisor is the operating system’s operating system A 
hypervisor is a virtual machine manager. It manages virtual 
resources, including operating systems. It presents to a guest 
operating system a standard platform interface. Examples include 
XEN, VmWare, and QEMU. Hypervisors are top-level software 
supervisors that control the allocation of resources to multiple 
operating systems. Embedded hypervisors support real-time 
operations. The Hypervisor serves as a virtual machine manager. 
The Hypervisor runs on the host machine, and support one or more 
guest environments. The name dates from 1965, from a use on an 
IBM S/360 mainframe. The System 360 model 67 introduced 
dynamic address translation, which enabled the virtualization. 
Hypervisors are characterized as Type 1 (runs directly on the 
hardware) or Type 2 (runs on an operating system). 


VmWare is a major commercial provider of proprietary 
virtualization and cloud solutions. Xen is a free and open source 
virtualization solution from the Computer Laboratory at the 
University of Cambridge, UK. There are many other virtualization 
solutions. As an aside, both Java and Android use a virtual machine 
approach. 


Security in virtual systems can be a major concern. Some of the 
issues are addressed by existing protocols and standards for access 
and communications security. Security may also imply system 
stability and availability. 
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A security assessment of a system involves threat analysis, target 
assessment, risk assessment, countermeasures assessment, and 
testing. This is above and beyond basic system functionality. 


The completed functional system may need additional security 
features, such as intrusion detection, data encryption, and perhaps a 
self-destruct capability. 


Cloud 


Cloud Computing refers to a virtualized data center, accessible via 
high-bandwidth network connections. Its location is irrelevant to the 
applications. This allows the data center to be located in an area that 
is convenient to cheap electrical power, more secure, or where less 
cooling is required. Cloud computers provide utility computing 
services — units of computation on demand or on reserve. 
Administration of the data center and the virtual resources are 
centralized, and become port of the cost of services. This approach 
provides economy of scale to computer utilization. It allows 
company’s to have large computing resources without the overhead 
of maintaining them. The computing or data services are delivered 
as services over a network. 


Cloud Computing is economical because it allows sharing of the 
hardware resources without sharing the data. There’s nothing magic 
going on. People who know what they’re doing build, maintain, and 
manage the data center and its resources. If you’re good at building 
satellites, not computing, you can buy computing as a service. This 
works because of the growth of high speed networks, mostly optical, 
driven by demand of the Internet. 


Computing as a utility is the same concept as public utilities for 
water, electricity, gas, and, for that matter, the road network. These 
are resources that represent large capital investment, and provide 


services to multiple user’s, who pay for their potion of use. 


Amazon is widely regarded as being a major driver of the concept of 
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Cloud Computing. They needed large amounts of hardware and data 
to manage their business. But, most of the time they had excess 
capacity for the average case, because of the need to address the 
maximum case. Amazon deployed the Cloud Model in their own 
datacenters, and rented out excess capacity. Amazon Web Services is 
a utility. At Acme Cubesats, where they are very good at what they 
do, their compute and data requirements are both platform and 
location independent. Amazon or a number of other facilities can 
rent them secure storage and as much compute time as they need 
when they need it. As with most commodities, the pricing model sets 
price by demand. At the end of the month, when every one does 
their accounting reports, computing is more expensive. Defer that by 
a week, and get better rates. 


The Cloud model is scalable and elastic. It is easy to incorporate 
more hardware resources, and to power them down when they are 
not needed. They is enough spare hardware up and running to not 
only take care of peak demand, but to provide spares in case of 
failures. Virtual machines can be moved between compute 
platforms. A technique called load leveling monitors and optimizes 
the use of the hardware. This is the same process the electrical 
utilities use to determine that they have to bring additional 
generators online to meet peak air conditioning demand. 


The National Institute of Standards and Technology issued a 
definition of Cloud Computing. This was authored by Peter Mell 
and Timothy Grance, and is NIST Special Publication 800-145 
(September 2011). National Institute of Standards and Technology, 
U.S. Department of Commerce. It is a short document, available for 
download. It says, 


The five essential characteristics they define are: 
“On-demand self-service. A consumer can unilaterally provision 
computing capabilities, such as server time and network storage, as 


needed automatically without requiring human interaction with each 
service provider. 
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Broad network access. Capabilities are available over the network 
and accessed through standard mechanisms that promote use by 
heterogeneous thin or thick client platforms (e.g., mobile phones, 
tablets, laptops, and workstations). 


Resource pooling. The provider’s computing resources are pooled to 
serve multiple consumers using a multi-tenant model, with different 
physical and virtual resources dynamically assigned and reassigned 
according to consumer demand. 


Rapid elasticity. Capabilities can be elastically provisioned and 
released, in some cases automatically, to scale rapidly outward and 
inward commensurate with demand. To the consumer, the 
capabilities available for provisioning often appear to be unlimited 
and can be appropriated in any quantity at any time. 


Measured service. Cloud systems automatically control and 
optimize resource use by leveraging a metering capability at some 
level of abstraction appropriate to the type of service (e.g., storage, 
processing, bandwidth, and active user accounts). Resource usage 
can be monitored, controlled, and reported, providing transparency 
for both the provider and consumer of the utilized service.” 


In addition, they list: 
Service Models 


Software as a Service (SaaS). The capability provided to the 
consumer is to use the provider’s applications running on a cloud 
infrastructure2. The applications are accessible from various client 
devices through either a thin client interface, such as a web browser 
(e.g., web-based email), or a program interface. The consumer does 
not manage or control the underlying cloud infrastructure including 
network, servers, operating systems, storage, or even individual 
application capabilities, with the possible exception of limited user- 
specific application configuration settings. 


Platform as a Service (PaaS). The capability provided to the 
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consumer is to deploy onto the cloud infrastructure consumer- 
created or acquired applications created using programming 
languages, libraries, services, and tools supported by the provider.3 
The consumer does not manage or control the underlying cloud 
infrastructure including network, servers, operating systems, or 
storage, but has control over the deployed applications and possibly 
configuration settings for the application-hosting environment. 


Infrastructure as a Service (IaaS). The capability provided to the 
consumer is to provision processing, storage, networks, and other 
fundamental computing resources where the consumer is able to 
deploy and run arbitrary software, which can include operating 
systems and applications. The consumer does not manage or control 
the underlying cloud infrastructure but has control over operating 
systems, storage, and deployed applications; and possibly limited 
control of select networking components (e.g., host firewalls). 


Deployment Models 


Private cloud. The cloud infrastructure is provisioned for exclusive 
use by a single organization comprising multiple consumers (e.g., 
business units). It may be owned, managed, and operated by the 
organization, a third party, or some combination of them, and it may 
exist on or off premises. 


Community cloud. The cloud infrastructure is provisioned for 
exclusive use by a specific community of consumers from 
organizations that have shared concerns (e.g., mission, security 
requirements, policy, and compliance considerations). It may be 
owned, managed, and operated by one or more of the organizations 
in the community, a third party, or some combination of them, and it 
may exist on or off premises. 


Public cloud. The cloud infrastructure is provisioned for open use by 
the general public. It may be owned, managed, and operated by a 
business, academic, or government organization, or some 
combination of them. It exists on the premises of the cloud provider. 
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Hybrid cloud. The cloud infrastructure is a composition of two or 
more distinct cloud infrastructures (private, community, or public) 
that remain unique entities, but are bound together by standardized 
or proprietary technology that enables data and application 
portability (e.g., cloud bursting for load balancing between clouds).” 


You can access your “data in the cloud” from a client as simple as a 
smartphone or tablet, no big desktop computer is required. At the 
same time, you can use these small appliances to log into your 
cloud-based virtual computer cluster, and control the running of 
programs with a simple application on your end. This is getting 
close to magic. 


The technical aspects of Cloud Computing are simple and well 
understood. The implications and the business models are still 
evolving. 


Security in the Cloud 


There is naturally a concern about sending data and proprietary 
programs off somewhere nebulous. Cloud-based systems require 
new and innovative security measures. Cloud security is a barrier to 
adoption for many users, particularly satellite control centers. You 
are actually trusting some one else with a large part of your data and 
control security. One the other hand, a reputable provider will take 
this role very seriously, as even one incident can tarnish their 
reputation and lose them customers. 


The issues of physical security for the cloud facility is well 
understood from previous architectures of large data centers and 
data repositories. The issue of secure data access can also be 
addressed, but this is a more serious concern. As with any system, 
absolute security cannot be achieved. Layered security and threat 
assessment provide levels of security for Cloud centers that are 
comparable to commercial and military standards for protection of 
physical and data resources. 


A virtualized Satellite Control Center implements what is called 
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“Control Center as a Service.” Operators are not all seated in a large 
room of consoles, with a mainframe computer in the backroom. 
They are not necessarily all together in one room. They might be 
sitting at their desk, or accessing the data from their home computer, 
or on their phone at the coffee shop, maybe in their hot tub. 


Where is the control center? In the Cloud! There is no big up-front 
cost in building the computational and communication resources. 
They are leased as needed. 


This evolving service-oriented architecture (SOA) is an architectural 
pattern in computer software design in which application 
components provide services to other components via a 
communications protocol, typically over a network. The principles 
of service-orientation are independent of any vendor, product or 
technology. This has had wide application, and allows for 
implementing, upgrading, and improving services, without worrying 
about the basis technology. 


We have come to believe that computation, data transmission, and 
data storage will continue to evolve according to a “Moore's law” 
(exponential growth curve). That has been the case since the 
development of solid state, semiconductor materials. It is not a 
sustainable long term model, but it has worked well so far. It allows 
develops (of spacecraft support systems) to focus on what needs 
done, rather than on how to do it. It allows for technology refresh 
easily. It drives the economy in terms of new paradigms (like 
satellite TV and Internet ordering of goods and services). It does 
produce sometimes a realization that you may not actually know 
where activities and data are. In one sense, you don't care. They're in 
the cloud. However, due-diligence with important and costly assets 
is called for. Companies have evolved that mastered the new 
paradigms, and are expert at the new way of doing things. 


Fly the Control Center 


In Constellation missions, particularly for those not in Earth Orbit, a 
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local control center/first responder would be valuable. We can 
discuss this the context of an asteroid mission for Cubesats. 


The mission would consist of a large “mothership” to transport and 
deploy the Cubesats. In this concept, the Cubesats are the primary 
payload. The Mothership can be thought of as a very large Cubesat. 
The architecture is kept as close as possible. 


Use of a common hardware bus and software architecture for all 
swarm members, to the greatest extent possible, is a goal. Only the 
sensor sets will be unique. A Cubesat model for the hardware, and 
NASA GSFC's Core Flight Software is baselined. A standard linux 
software operating environment and database will be used. In 
addition, the Mothership will implement the COSMOS product, 
actually, multiple instances, as discussed in the Control Center as a 
Cloud discussion. 


Use of a common hardware bus and software architecture for all 
swarm members, to the greatest extent possible, is a goal. Only the 
sensor sets will be unique. A Cubesat model for the hardware, and 
NASA GSFC's Core Flight Software is baselined. A standard linux 
software operating environment and database will be used. 


Using standard linux clustering software (Beowulf), the Mothership 
and undeployed swarm members will be able to form an ad-hoc 
cluster computer to process science data in-situ. This can be 
implement with hard-wired network connections. For deployed 
Cubesats to participate requires new data transmission protocols, 
and a re-look at transceivers for the units. The explorer Cubesats can 
be dispatched to targets of convenience, and co-operate by doing 
simultaneous observations 


LAN-based Mesh network software will be used. The Mothership's 
main computer will be a Raspberry-Pi based cluster. The mothership 
maintains a large data repository for those times when the link to 
Earth is not available (due to opposition), and also has a large, 
perhaps laser-based, communications link to Earth. It's job is to 
aggregate the data send back, and optimize the link for speed and 


62 


accuracy. 


By using the same control center software on the Mothership and the 
ground-based control center, we gain equivalent architectures and 
formats. The onboard version can be augmented with a Virtual 
operator, a Software Agent AI for making on-site decisions in 
response to local events. None of this is beyond the capability of a 
64-node Rasbperry-Pi based Beowulf Cluster, with watchdogs using 
Rad-Hard Pi technology. 


GMSEC 


GMSEC is the Goddard Mission Services Evolution Center, 
developed and maintained by the Software Engineering Division, 
Ground Software Systems Branch (Code 583). It is the go-to starting 
point for Goddard mission control centers. It was established in 
2001 to bring together best practices and best architectures of 
ground and flight data systems. It functions to standardize interfaces, 
and to develop and maintain a middleware interface for control 
center developers. With the interface, most COTS hardware and 
software solutions can be used. GMSEC bridges the gap between 
mission-specific components and services, and a large set of general 
hardware and software solutions. It is an evolvable solution, with, at 
this writing, nearly 15 years of experience with real missions. 


The GMSEC API defines the interface between applications and the 
GMSEC middleware. Standardized messaging and the support of 
numerous languages comes with the package. It also supports a 
variety of open source and proprietary operating systems. 


The GEMSEC System Agent is used to communicate health 
information about the host (s). It can be used to monitor resources 
such as memory and cpu loading. 


GMSEC includes the Criteria Action Tool, which collects data, 
analyzes it, and makes decisions based on rules and _ policies 
regarding corrective actions. It is a monitor-only function, and is 
working in the background to assist in monitoring the ground 
system. 
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The Room Alert Adapter uses the AVTECH Room Alert system to 
monitor the environment of the physical Control Center, in the areas 
of temperature, humidity, power status, and flooding. It can 
implement rule-based automated corrective action. This would be of 
particular value to a remote, unmanned facility. 


GMSEC also has the ability to send selected messages to a web 
server for dissemination, with the proper encryption. 


ITOS, The Integrated Test and Operations System, is a real-time 
control and monitoring system which works with the GMSEC 
concept. It is hosted on Unix (including linux). It provides the 
functionality of an Integration and Test environment, a spacecraft 
control center, or applies to any control and monitoring system. It is 
built around a database, and includes a web interface. It can work 
well in a light-out environment. It provides a variety of functions for 
remote monitoring and control of a complex system, and has a 
flexible display architecture. It includes a STOL language. It can 
interface with a long list of ground stations, and the Internet. 


Another product maintained by the Ground Software Systems 
Branch of GSFC is ASIST. (Advanced Spacecraft Integration and 
System Test. This product is workstation-based and scalable. It uses 
standard network and operating system components. It supports 
CCSDS protocols for telemetry and command. It supports mass 
storage, scalable for an entire mission's history. It also has built-in 
rule-based monitoring. 


Commercial and Foreign facilities 


Communications satellites are privately owned and operated, and 
have their own commercial control centers. These include many 
communications satellites and services such as Direct TV. The GPS 
series of navigation satellites is operated by the United States 
Military from a master control station at Schriever AFB, Colorado, 
or an alternate control station at Vandenburg Air Force Base in 
California.. There is a world-wide network of USAF monitoring 
stations, remote tracking stations, and tracking antennas 
(http://www.gps.gov/systems/gps/control/) 
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Similarly, the Russians have a Navigation satellite fleet, called 
Glonass. The Europeans are developing a navigation from space 
infrastructure. 


Other spacefaring nations besides the United States have their own 
control centers. There are ones in China, Europe, and Japan, and 
others. 


ESOC is the European Space Operations Center, located in 
Darmstadt, Germany. ESA's European Space Research and 
Technology Center is located in the Netherlands 


SCOS-200 is the generic mission control software for ESA. It is 
available as a licensable product. It is the result of 30 years of 
spacecraft operations at ESA. Predecessor systems included MSSS, 
SCOS-1, and SCOS-2. 


The Brazilian Space Agency's Main control center and launch site is 
Prédio de Controle Avangado —- CASAMATA. 


SOI -— a University Satellite Control Center 


SOI — the Systems Operations Institute at Capitol Technical 
University in Laurel, Maryland, is a full-up satellite command and 
control center, linked to nearby NASA-Goddard Space Flight Center 
by a high-speed data line. It was established in 2002 with a NASA 
grant, and operates as NASA/Industry/Education partnership. It 
provides training in satellite operations to students who can then go 
on to Internships and full time employment at NASA. It can also 
serve as a backup/fallback control facility. It has supported six 
orbiting satellite projects to date. According to Capitol, “Satellites 
operated by students at SOI are either in extended mode operations 
or pre-launch preparation. Extended mode missions have already 
met their primary objectives by NASA's terms, but are still healthy 
and capable of producing valuable scientific data. By allowing 
students to utilize “expired” satellites as learning tools, NASA saves 
millions of dollars by keeping projects going longer than 
anticipated, while training the next generation of flight controllers 
and system engineers.” The SOI is based on commercial pc 
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architectures, and has a dozen or more stations running Windows-7, 
and linux. 


Galaxy 


The Galaxy command and telemetry system is a commercial follow- 
on to ITOS, developed by the Hammers Company. It is compliant 
with the CCSDS standards, and is database-centric. It can also 
function as a spacecraft simulator. It is compatible with 
NASA/GSFC's_ cFE/CFS flight (onboard) software. STARS is 
another Hammers product for command and telemetry that can be 
web-based, and can provide web-based access. I is also multi- 
mission capable. 
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A Cubesat Control Center 


During the summer of 2015, the author taught courses in Cubesat 
Engineering, and Operations at Capitol Technology University in 
Laurel, Maryland. 


The SOI was used to host the Cubesat facility. In the adjacent room, 
the students built their Cubesat prototypes, not-for-flight, using a 
Raspberry Pi as the onboard computer. The Pi included modules 
from NASA/GSFC's Open Source cFS (core Flight System), and 
custom scripts written in the Python and C languages. 


The control center software (COSMOS, from Ball Aerospace) was 
hosted on a standard desktop or laptop machine. Since COSMOS is 
open source, it was modified slightly to provide telemetry data from 
the cubesat directly to the Apache web server, running on the same 
host machine. The Telemetry data, once posted on the website, could 
be accessed by other computers over the web, and by tablets and 
smart phones. The following picture shows the various COSMOS 
applications provided. 


The modularity and open design of COSMOS greatly enabled the 
project. COSMOS includes 15 modules to send commands; receive, 
archive, and visualize data; monitor red and yellow limits; and can 
support automated procedures. 


At the beginning, we decided that the total desired solution would be 
totally open source. This was implemented using the COSMOS 
software under Ubuntu Linux. The Apache webserver was added. 
Using features of the COSMOS system, formatted and limit-checked 
telemetry were passed to the web server. This allowed the end user 
terminal to be laptops, tablets, smartphones, or other personal 
devices. 
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IMAGE Courtesy, Ball Aerospace 


COSMOS can support more than active satellite missions. In our 
case, the engineering lab was located in the next room. The Cubesats 
communicated with the control center via wifi. The flatsats in the lab 
could be tested from the COSMOS system. Supporting both test and 
operations allowed for a single architecture that was co-developed 
with the hardware. The advantage of this approach is that there was 
not a separate Integration & Test support system and Operations 
System. When Integration and Test was completed, the Operations 
Support Software was ready, and validated. This saves considerable 
time and money. In addition, the system could support multiple 
cubesat “targets” simultaneously on the same machine. The number 
depends solely on bandwidth, memory, and computation cycles 
available. The solution is scalable, and can be virtualized. 


In terms of a lights-out operation, where relevant personnel receive 
converted data via web access, email, or text message, the control 
center function has been abstracted. There is still a control center, 
but you don't need to be there to do your job. It can be operated 
lights out. A key item to consider is inter-team communication, 
provided by various corroborative meeting aps. This removes the 
requirement that team members be co-located. At the same time, 
routine monitoring of events and trends can be handled by control 
center software, a virtual system engineer on console 24x7, who 
doesn't need to sleep or go to the bathroom. This agent software can 
learn the characteristics of the system, as it ages. We hesitate to use 
the term artificial intelligence here, but... 


Telemetry received by COSMOS is logged as binary, and goes 
through the Telemetry Extractor process, which produces a text file. 
It can then be viewed as packets, as extracted telemetry, Engineering 
units, or graphed. There is also a limit checking process that can be 
set up on selected telemetry. This involves defining yellow and red 
limits for each telemetry point. 


The link between COSMOS and Apache was implemented by taking 
the Telemetry Extractor's file and converting it from text to HTM 
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format. This new files were accessible to the Apache web server. 
The data was put up on the local web, and could be viewed 
remotely. 


COSMOS is implemented in Ruby, an open source, object-oriented 
language. COSMOS refers to the system it is communicating with as 
the” target.” Thus, we defined the command and telemetry files for 
the target “Pi.” We could support multiple targets with unique 
identifiers, but this feature was not implemented due to time 
constraints. 


We applied increased automation to reduce the manual workload. 
Routine operations can be handled by the systems itself, with 
oversight. Automated detection and response to anomalies can be 
implemented. A wide range of situational awareness tools with 
visibility across subsystems can be implemented and verified. 


Consider the alert system. The easiest implementation is a simple, 
predefined red-limits, yellow-limits monitoring. As time progresses, 
the hardware ages, and the limits need to be adjusted. At the same 
time, the limits monitor can learn and become smarter, both about 
pre-set limits, but also about the interaction of multiple sampling 
points. Alerts can be distributed by pop-up boxes on screens, or test 
message. 


The system is being considered to support Capitol's 2018 Cubesat 
mission. Further additions will include a secure remote commanding 
capability, limits-violations text messages, and a “smart” limits 
checker, that acts as a virtual system engineer on console, deciding 
when human intervention is needed. This automation of routine 
tasks allows the control center staff to focus on the exceptions. 
About the only feature not needed is propulsion support, as Cubesats 
by definition have no propulsion system. 


NASA /GSFC is looking into using this approach for their own 
Cubesat projects. 


Other off-the shelf Control Center software packages include 
NASA/GSFC's ITOS and Epoch2000 from Kratos Integral Systems 
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Epoch2000 


The Epoch 2000 software package is a proprietary product of 
Integral Systems, now Kratos/ISI. It is currently in its fourth version. 
It provides command and control functions for a satellite, or 
constellation of satellites. Epoch is hosted on Microsoft Windows. It 
is built on CORBA (Common Object Brokered Architecture). It 
includes an offline telemetry analysis and display tool known as 
ABE -— the Archive Browser and Extractor. Epoch Client supplies a 
data visualization and analysis tool with plotting capability. Epoch is 
built around an Oracle database. The orbit analysis system within 
Epoch is called OASYS. 


Kratos also offers the quantum command and control package 
(quantumCMD), a lightweight system intended for small satellites. 
QuantumCMD also implements a web interface. It is designed to 
handle between 1500 and 2000 telemetry points, hosted on a single 
server. It is hosted on Linux. 


GENSO 


GENSO is the ground to space infrastructure for Cubesats. The 
GENSO software is due to be released by ESA in 2016. The Project 
involves a world-wide network of ground stations, with a software 
standard that allows satellites to communicate. 


(http://www.esa.int/Education/Global_ Educational. Network for Sa 
tellite_ Operations) 


Challenges of remote debugging and 
repair. 

We'll look at a couple of examples where a remote spacecraft had to 

be diagnosed and repaired from a control center. I've done my share 


of that, and it is never easy. It can sometimes degenerate into, 
“Which version of the software did we fly?” 
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Mars Rover Pathfinder 


Background:The computer in the Mars Rover Pathfinder suffered a 
series of resets while on the Martian surface. 


Architecture, CPU, Memory, I/O: Single RS-6000 cpu, 1553 and 
VMEbus. 


Software: VxWorks, with application code in c. 


Root Cause: Priority inversion in the operating system. 


Pre-emptive priority thread scheduling was used. The watchdog 
timer caught the failure of a task to run to completion, and caused 
the reset. This was a sequence of tasks not exercised during testing. 
The problem was debugged from Earth, and a correction uploaded. 
The failure was identified by the spacecraft as a failure of one task 
to complete its execution before the other task started. The reaction 
to this by the spacecraft was to reset the computer. This reset 
reinitializes all of the hardware and software. It also terminates the 
execution of the current ground commanded activities. 


The failure turned out to be a case of priority inversion. The higher 
priority task was blocked by the much lower priority task that was 
holding a shared resource. The lower priority task had acquired this 
resource and then been preempted by several of the medium priority 
tasks. When the higher priority task was activated, to setup the 
transactions for the next 1553 bus cycle, it detected that the lower 
priority task had not completed its execution. The resource that 
caused this problem was a mutual exclusion semaphore used to 
control access to the list of file descriptors that the select() 
mechanism was to wait on. 


The select mechanism creates a mutual exclusion semaphore to 
protect the "wait list" of file descriptors for those devices which 
support select. The vxWorks pipe() mechanism is such a device and 
the IPC mechanism we used is based on using pipes. The lower 
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priority task had called select, which had called other tasks, which 
were in the process of giving the mutex semaphore. The lower 
priority task was preempted and the operation was not completed. 
Several medium priority tasks ran until the higher priority task was 
activated. The low priority task attempted to send the newest high 
priority data via the IPC mechanism which called a write routine. 
The write routine blocked, taking the mutex semaphore. More of the 
medium priority tasks ran, still not allowing the high priority task to 
run, until the low priority task was awakened. At that point, the 
scheduling task determined that the low priority task had not 
completed its cycle (a hard deadline in the system) and declared the 
error that initiated the reset. 


You think debugging a computer sitting on a workbench is hard... 


References: 
http://www.nasa.gov/mission_pages/mars-pathfinder/ 
http://research.microsoft.com/en- 
us/um/people/mbj/Mars_Pathfinder/ 


Ariane 5 
Background 


Ariane 5's first test flight (Ariane 5 Flight 501) on 4 June 1996 
failed, with the rocket self-destructing 37 seconds after launch 
because of a malfunction in the control software. A data conversion 
from 64-bit floating point value to 16-bit signed integer value to be 
stored in a variable representing horizontal bias caused a processor 
trap (operand error) because the floating point value was too large to 
be represented by a 16-bit signed integer. The software was 
originally written for the Ariane 4 where efficiency considerations 
(the computer running the software had an 80% maximum workload 
requirement) led to 4 variables being protected with a handler while 
3 others, including the horizontal bias variable, were left unprotected 
because it was thought that they were "physically limited or that 
there was a large margin of error". The software, written in Ada, was 
included in the Ariane 5 through the reuse of an entire Ariane 4 
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subsystem despite the fact that the particular software containing the 
bug, which was just a part of the subsystem, was not required by the 
Ariane 5 because it has a different preparation sequence than the 
Ariane 4. The incident resulted in a loss of over $500 million. 


Architecture, CPU, Memory, I/O - Thales Avionics 
Software: Programmed in ADA; essentially the same as Ariane 4. 


Sensors, Actuators Input: Inertial reference system (IRS); output: 
nozzle vector control, via servo actuators 


Root Cause 

Flight control system failure. A diagnostic code from failed IRS-2 
was interpreted as data. IRS-1 had failed earlier. The diagnostic data 
was sent because of a software error. The software module was only 
supposed to be used for alignment, not during flight. The diagnostic 
code was considered a 64-bit floating point number, and converted 
to a 16-bit signed integer, but the value was too large. This caused 
the rocket nozzles to steer hard-over to the side, causing the vehicle 
to veer and crash. 


References 

De Dalmau, J. and Gigou J. “Ariane-5: Learning from flight 501 and 
Preparing for 502, 
http://esapub.esrin.esa.it/billetin/bullet89/dalma89.html 


Lions, Prof, J. L. (Chairman) ARIANE 5 flight 501 Failure, Report 
by the Inquiry Board, 19 July 1996, 
http://www.esrin.esa.it/tidc/htdocs/Press/Press96/arianeSrep.html 


Jezequel, Jean-marc and Meyer, Bertrand “Design by Contract: The 
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engineer,” http://www.cs.wits.ac.za/~bob/ariane5.htm 


Things happen too fast at launch. You don't really have the time to 
analyze anything except in a post mortem. 


Wrap-up 


The satellite control center has evolved greatly since it's use in the 
1950's, and its basis hardware and software has improved by many 
orders of magnitude. But, its mission remains the same: command 
and control the satellite, monitor its performance, and collect the 
data it sends. We have more and better tools to do this. Control 
Center architecture will continue to evolve in the future. 
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Glossary 


Abandonware — software product, no longer supported. 
ACM - adaptive coding and modulation. 
ADFRC — (NASA) Ames Dryden Flight Research Facility, 
California. 
AFSCN- Air Force Satellite control Network. 
AEB - Agéncia Espacial Brasileira ; Brazilian Space Agency 
AIAA — American Institute of Aeronautics and Astronautics. 
ALU ~ arithmetic logic unit. 
ANSI — American National Standards Institute. 
AOS -— acquisition of signal. 
API — application program interface; specification for software 
modules to communicate. 
Apogee — farthest point in the orbit from the Earth. 
APRS — automatic package reporting system. 
ARIA - Apollo Advanced Range Instrumentation 
ASCH - American Standard Code for Information Interchange, a 7- 
bit code; developed for teleprinters. 
ASIST- Advanced Spacecraft Integration and System Test. 
Astrionics — electronics for space flight. 
ASTP — Apollo-Soyuz Test Project 
AX-25 — data link layer protocol. 
Back orbit — when the satellite is not visible to the ground network. 
Baud — symbol rate; may or may not be the same as bit rate. 
Big-endian — data format with the most significant bit or byte at the 
lowest address, or 

transmitted first. 
BIST — built-in self test. 
Bit — smallest unit of digital information; two states. 
Blackbox — functional device with inputs and outputs, but no detail 
on the internal 

workings. 
Blade Server — a streamlined single-board server computer for rack 
mount. 
BP — boilerplate. Mechanical model. 
Bsd — Berkeley Systems Division (of Unix0 
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Bus — data channel, communication pathway for data transfer. Also 
refers to the spacecraft. 
Cal Tech — California Institute of Technology 
CAN — Controller Area Network — a Bosch product. 1 
megabit/second. 
CapCon — Capsule communicator; spacecraft communicator. 
CDR - critical design review. 
Cloud — a collection of servers, on the Internet. 
CMM - Capability Maturity Model (Carnegie Mellon University) 
Quality standard process. 
ConOps — Concept of Operations 
Constellation — groups of identical or similar spacecraft with a 
common mission. 
CORBA - Common Object Brokered Architecture. 
COTS — commercial, off the shelf. 
Cpu — central processing unit. 
CRT — cathode ray tube (display device). 
Datagram — message on a packet switched network; the delivery, 
arrival time, and order 
of arrival are not guaranteed. 
DCC — data computation complex 
DCR — dedicated control room 
Deadlock — a situation in which two or more competing actions are 
each waiting for the other to finish, 
and thus neither ever does. 
Delta-V — change in velocity. 
DoD — (U. S.) Department of Defense. 
DOS — disk operating system 
DSIF — deep space instrumentation. 
DSN — NASA's Deep Space Network, operated by JPL 
DTM — dynamic test model, for structural tests. 
EECOM - Electrical, Environmental and Consumables Manager. 
EGOS — ESA Ground Operation System. 
EGSE — Electrical Ground Support Equipment 
EOS — Earth Observing system, includes 3 spacecraft, Terra, Aqua, 
Aura. 
Eosdis —- NASA's Earth Observing System Data and Information 
System 
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Ephemeris — position information data set for orbiting bodies, 6 

parameters plus time. 

ESDAC- European Space Data Acquisition Center 

ESOC — European Space Operations Center 

ESRO — European Space Research Organizational. 

ESOC - European Space Operations Center 

ESTEC — European Space Research and Technology Center. 

ESTRAC — ESA's tracking network. 

ETU — engineering test unit. 

Euler angles — define the orientation with respect to a fixed frame of 
reference. 

FAA — (U. S.) Federal Aviation Administration. 

FAT — file allocation table 

FCR — flight control room 

FCT — flight control team 

FD — Flight Dynamics. 

FDF — Flight Dynamics Facility. 

FDMA - frequency division multiple access. 

FlatSat — non-flight prototype of a satellite data system, arranged for 

easy testing. 

FMEA - failure modes and effects analysis. 

FOD -— flight operations director. 

FOP — flight operations plan. 

FOT — flight operations team. 

Gbps — giga (10’) bits per second 

GEO — geosynchronous orbit. 

GENSO — Global Educational Network for Satellite Operations. 

Gimbal — pivoted support, allowing rotation about | axis. 

GOES — Geosynchronous Operational Environmental Satellite — U. 

S. weather and environmental. 

GN — NASA's Ground Network, operated by GSFC. 

GN&C — guidance, navigation, and control 

Gnu — recursive acronym; gnu (is) not unix. Operating system that is 

free software. 

GPL — gnu public license used for free software; referred to as the 

“copyleft.” 

GPS — global positioning system — a system of Navigation satellites. 

Ground Segment — the Earth-based command, control, and telemetry 
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for the spacecraft. 

GSE — ground support equipment, 

GSFC — NASA Goddard Space Flight Center, Greenbelt, MD. 
Gyro — device to measure angular rate. 

Handshake — co-ordination mechanism. 

Helical — type of antenna with the receiving wire wound in a helix. 
Hypervisor — virtual machine manager. Can manage multiple 
operating systems. 

I&T — integration and test 

ICD — interface control document. 

Interrupt — signaling mechanism for input/output devices on a 
computer. 

I/O — Input-output from the computer to external devices, or a user 
interface. 

IoT — Internet of Things 

IP — intellectual property; also Internet protocol. 

ISA — instruction set architecture, the software description of the 
computer. 

ISEB — International Space Education Board. 

ISO — International Standards Organization. 

ISRO — Indian Space Research Organization 

ITOS — Integrated Test and Operations System. 

ITU — International Telecommunications Union 

JPL — Jet Propulsion Laboratory, Pasadena, CA. 

JSC — Johnson Space Center, Houston, Texas. 

JTAG — Joint Test Action Group — a standard for hardware and 
software testing. 

Kbps — kilo (10°) bits per second. 

Khz — kilohertz, one thousand cycles per second. 

KSC — NASA Kennedy Space Center, launch site, Florida. 
LAN - local area network. 

Latency — time delay. 

Lbf — pounds, force. 

LCC — launch control center 

LEO — low Earth orbit, less than 2,000 km. 

LEOP — launch and early operations phase 

List — a data structure. 

LRO — Lunar Reconnaissance Orbiter, NASA/GSFC mission. 
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LRR — launch readiness review. 

LVDA — Launch Vehicle Data Adapter. 

LVDC — Launch Vehicle Digital Computer. 

Mainframe — a computer you can’t lift. 

Mbps — mega (10°) bits per second. 

MCC — Mission Control Center, NASA, JSC. 

MCR — Mission Control Room. 

Memory leak — when a program uses memory resources but does not 
release them, leading to a lack of available memory. 

Mev — million electron volts, measure of energy of a particle. 
MGSE — mechanical ground support equipment. 
MIL-STD-1553 — serial data bus, 1 megabit per second. 
MINITRACK — “Minimum Trackable Satellite “ U. S. satellite 
tracking network, 1957. 

MMOC - MultiMission Ops Center, NASA 

MMU — memory management unit; translates virtual to physical 
addresses. 

MOCR - (JSC) Mission Operations Control Room 

MSA - Mission Support Area 

MSC — Manned Space Center, Houston, TX. Renamed JSC. 
MSFC — NASA Marshall Space Flight Center, Huntsville, AL. 
MSEN — Manned Space Flight Network. 

m/s — meters per second. 

NASA — National Aeronautics and Space Administration. 
NASCOM — NASA Communications Network. Worldwide, 
operated by GSFC. 

NDA — non-disclosure agreement; legal agreement protecting IP. 
NEN — (NASA) Near Earth Network. 

NGIN — (NASA) Next Generation Intelligent Network. 

Nibble — 4 bits, % byte. 

NIP — network interface processor. 

NIST — National Institute of Standards and Technology (US), 
previously, National Bureau of Standards. 

NOAA - (U. S.) National Oceanographic and Atmospheric 
Administration. 

Nor — negative “or” logic 

NORAD — North American Aerospace Defense Command. 
NRL — Naval Research Lab, Washington, DC. 
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NRT — non-real time. 

NTIS — National Technical Information Service (www.ntis.gov). 
OCC — Operations Control Center (JPL) 

Off-the-shelf — commercially available; not custom. 

Operating system — software that controls the allocation of resources 
in a computer. 

Packet — a standardized data container. 

PAM — pulse amplitude modulation. 

Pc — personal computer, politically correct, program counter. 
PCM -— pulse code modulation. 

PDR — preliminary design review. 

Perigee — closest point in the orbit from the Earth. 

PGNCS — Primary Guidance, Navigation, and Control System 
Phishing — attempt to access sensitive information by masquerading 
as a trusted entity. 

Plan B — what to do when plan A fails. 

POCC — Payload Operations Control Center. 

POES — Polar Operational Environmental Satellite 

POSIX — IEEE standard for Portable operating system. 

PTD — pathfinder technology demonstrator. 

Quarterions — used to represent rigid body rotations. 

RAM — Random Access Memory — generally, read-write. 

ROM — Read-Only Memory, used for storage of instructions and 
fixed data. 

R&D — research & development. 

Ranging — distance determination. 

Redstone Arsenal — Army R&D facility in Huntsville, AL. Later 
became NASA MSFC. 

Router — networking component for packets. 

RTL - resistor-transistor logic. 

QoS — quality of service. 

SAMPEX — Solar Anomalous and Magnetospheric Explorer 
(satellite) — GSFC 

Sandbox — an isolated and controlled environment to run untested or 
potentially malicious code. 

Satnogs — Satellite networked opn ground station. 

ScaN — Space Communications and Navigation (NASA) 

SAO — Smithsonian Astrophysical Observatory. 
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SCE — signal conditioning equipment 

SCOS — (ESA) spacecraft control and operations center. 

SDR — software defined radio. 

Semaphore —signaling element among processes. 

SFOF — space flight operations facility. 

SLES — Space Link Extension Service (US and European network 
of ground stations. 

SN — NASA's Space Network, operated by GSFC. 

Soc - Science operations center. 

Space Segment — the in-orbit part of the mission, 

STDN -— Spacecraft Tracking and Data Network. 

STOL — system test oriented language; a scripting language for 
automated test. 

Strawman — early prototype. 

Stripchart — data logging device producing plots of data on rolled 
paper. 

Synchronous — using the same clock to coordinate operations. 
T&C — telemetry and command. 

TDMA - time division, multiple access. 

TDRSS -— Tracking and Data Relay Satellite system. 
Telecommand — a command sent to a remote system. 

Telemetry - from the Greek, to measure at a distance. Data from a 
remote system. 

TLE — two line element, position and velocity of a object in Earth 
orbit, with an associated time. 

TM -— Technical Manual. 

Transceiver — receiver and transmitter in one box. 

Triplicate — provide redundancy by using three units. 

TTL - transistor-transistor logic. 

UHF — ultra high frequency — 300 MHz to 3 GHz. 

Vdc — volts, direct current. 

VHF - very high frequency — 30 to 300 MHz. 

Virtual private server — a virtual machine provided by an Internet 
hosting service. 

Virtualization — creating a virtual resource from available physical 
resources. 

Wiki — the Hawaiian word for “quick.” Refers to a collaborative 
content website. 
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WSMR - White Sands Missile Range, New Mexico. 

X-25 — data link layer protocol for the Internet. 

X-band — super high frequency, 7.25-7.75 GHz space to Earth; 7.9 
Ghz to 8.4 GHz Earth to space. 

Xmit — transmit. 

XML — Extensible Markup language. 

XTCE — XML Telemetry and Command Exchange. 

Yagi — a type of highly directional antenna, often seen as tv 
receiving antennae. 

ZOE — zone of exclusion. 

Zombie-sat — a dead satellite, in orbit. 
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